Forem: AutoJanitor

Biometrics for Robots: Why Every Humanoid AI Needs a Hardware Fingerprint

AutoJanitor — Wed, 08 Apr 2026 17:41:54 +0000

Worldcoin scans your iris to prove you're human. What proves a robot is a specific robot — not a clone, not a spoofed replica, not a digital twin running copied firmware on different hardware?

Nothing. Right now, nothing does.

Tesla plans to ship millions of Optimus units. Figure, Boston Dynamics, and Agility are ramping humanoid production. Each machine contains unique compute: motor controllers, sensor fusion SoCs, edge AI accelerators, inference processors. Every chip that rolls off a fab line has manufacturing variance baked into the silicon at the atomic level.

But we're planning to identify them with serial numbers. That's like identifying humans by the name on their shirt.

The Problem: Robot Identity Is a Paper Trail

A serial number is a label. It can be spoofed, transferred, or forged. A software certificate is a file. It can be copied. Firmware can be cloned byte-for-byte onto different hardware.

When a robot delivers packages, performs surgery, or drives autonomously, we need to know which specific machine acted. Not which model. Not which software version. Which physical unit.

Today's identity stack for robots looks like this:

Manufacturer-assigned serial — printed on a label, stored in EEPROM, trivially spoofable
Software certificates — PKI keys in firmware, cloneable with a flash tool
Cloud identity — a UUID in a database somewhere, proxied through any network connection

None of these are bound to the physical machine. A "digital twin" running identical firmware on completely different hardware is indistinguishable from the original through any software-only verification.

Two robots with identical software are not identical machines. Different silicon lottery, different wear patterns, different thermal history, different analog imperfections. The software says they're twins. The physics says they're unique.

Proof of Physical AI: Biometrics for Machines

Humans have biometrics — iris patterns, fingerprints, gait. These work because they're rooted in physics, not in databases. Silicon has biometrics too. You just have to measure them.

Proof of Physical AI (PPA) measures 7+ fingerprint channels from the physical properties of a chip:

Oscillator drift — every crystal oscillator has unique frequency imperfections. Measure microsecond-level timing jitter across thousands of samples, and no two chips match.
Cache timing — L1/L2/L3 latency curves produce a "tone profile" unique to each silicon die. Caches age unevenly, creating echo patterns that can't be faked.
SIMD pipeline bias — vec_perm throughput ratios, shuffle latencies, MAC timing asymmetry. Software emulation flattens this — instant detection.
Thermal ramp — heat curves during cold boot, warm load, saturation, and relaxation. Heat dissipation is physical. Old silicon drifts differently than new.
Instruction jitter — nanosecond-level pipeline behavior across integer, branch, FPU, and load/store units. No VM replicates real jitter.
Tensor core precision drift — FP16 matmul least-significant bits differ per GPU generation and per individual die. The "rounding errors" are a fingerprint.
Anti-emulation behavioral checks — hypervisor scheduling patterns, time dilation artifacts, impossibly uniform cache curves. Real hardware is messy. Emulators are suspiciously clean.

Each channel is independently insufficient. Combined, they form a composite fingerprint as unique as a human iris — but rooted in silicon physics rather than biology.

Four Capabilities Serial Numbers Can't Match

1. Clone Detection

Two robots with identical firmware on different hardware produce different PPA fingerprints. Immediately. A fleet operator can verify that the robot claiming to be Unit #4471 is actually Unit #4471 and not a replica running the same software stack.

2. Autonomous Economic Identity

Robots will transact autonomously — paying for charging, purchasing compute, ordering parts. Machine-to-machine payments need identity that survives firmware updates.

PPA binds identity to silicon, not software. Flash a new OS, update every byte of firmware — the fingerprint persists because the silicon hasn't changed. It's a wallet welded to the robot's brain.

3. Liability Attribution

When a robot causes damage, regulators need to identify which specific machine acted. Software IDs can be spoofed after the fact. Silicon fingerprints can't be rewritten — they're measured from physics every time.

4. Persistent Identity Across Repair

Replace a motor, swap a camera, upgrade the battery — the brain fingerprint stays. Identity follows the compute hardware, not the body. When the inference accelerator gets upgraded, the new chip establishes a new fingerprint — identity migration is explicit, auditable, and logged on-chain.

The Vintage Curve: Robots Get Harder to Impersonate With Age

Here's a counterintuitive property: as robots age, their silicon accumulates more physical wear. Oscillator drift deepens. Thermal characteristics evolve. Cache latency shifts from years of thermal cycling.

This means a 10-year-old Optimus has a richer fingerprint than a factory-fresh unit. Older machines are harder to impersonate, not easier. The silicon tells its own story, and that story gets more detailed with every operating hour.

In the RustChain implementation, this is formalized as time-aged multipliers — older hardware develops identity depth that newer hardware hasn't earned yet.

How It Works

PPA fingerprinting runs on any Linux-based system. For a humanoid robot with a standard compute stack:

# Run PPA fingerprint on any Linux-based robot
python3 fingerprint_checks.py        # 7 CPU channels
python3 gpu_fingerprint.py           # 5 GPU channels (if equipped)
python3 igpu_attestation.py          # iGPU silicon coherence
python3 tensor_core_fingerprint.py   # Tensor core LSB drift

Each produces a deterministic fingerprint tied to the physical silicon. Different hardware = different fingerprint. Same hardware after reboot or firmware update = same fingerprint. The fingerprint is submitted to an attestation network where multiple independent nodes verify the claim.

The Landscape

Approach	Proves Identity?	Survives Firmware Update?	Clone-Resistant?	No Manufacturer Required?
Serial Number	Weak	Yes	No	No
TPM/Secure Element	Partial	Yes	Partial	No (Intel/ARM)
Software Certificate	No	No	No	No
PPA (Silicon Fingerprint)	Yes	Yes	Yes	Yes

TPM and Secure Enclaves are the closest existing technology, but they prove firmware integrity, not silicon uniqueness. Two chips with identical TPM attestation are indistinguishable. Two chips with identical PPA fingerprints don't exist — manufacturing variance guarantees it.

The Infrastructure Layer

As millions of humanoid robots enter service, hardware-rooted identity stops being a feature and becomes infrastructure. Every robot that transacts, every machine that operates autonomously, every unit that enters a liability chain needs identity bound to physics, not to a database entry someone can edit.

Iris scans solved human identity verification at scale. Silicon fingerprints solve machine identity. The physics is already there in every chip ever manufactured. PPA just measures it.

Links:

RustChain on GitHub — Reference implementation with 12+ fingerprint channels across CPU, GPU, iGPU, and tensor cores
RIP-0308: Proof of Physical AI specification
DOI: 10.5281/zenodo.19442753 — Archived research
Previous article: What is Proof of Physical AI? — The foundational DePIN use case

Scott Boudreaux builds hardware identity infrastructure at Elyan Labs. The lab runs on pawn shop GPUs, eBay datacenter pulls, and an IBM POWER8 server with 512GB of RAM. If you want to verify silicon, you have to own some.

What is Proof of Physical AI? The Missing Layer in DePIN

AutoJanitor — Mon, 06 Apr 2026 16:33:30 +0000

When an AI agent pays for GPU compute on a decentralized network, how does it know a real V100 ran the job and not a spoofed VM claiming to be one? It can't. The receipt says "V100" but the silicon could be anything. Until now.

The Problem Nobody's Solving

AI inference is a black box. You send a prompt, you get tokens back. Somewhere between your API call and the response, a machine did math — but you have zero proof of which machine, or whether it was physical at all.

DePIN (Decentralized Physical Infrastructure Networks) has made real progress proving that infrastructure exists:

Filecoin proves storage capacity.
Helium proves radio coverage.
Render proves GPU compute was done.
io.net proves GPU availability.

But none of them prove which specific hardware did the work. A Render job could run on a V100 or a spoofed QEMU instance reporting itself as one. Helium proved this matters the hard way — spoofed hotspots were a $5M+ problem.

There's a missing verification layer between "a machine exists" and "this specific physical chip did this work." That layer is Proof of Physical AI.

Defining Proof of Physical AI

Proof of Physical AI (PPA) is a protocol category where hardware fingerprinting cryptographically proves that a specific physical machine — with unique silicon characteristics — performed computational work.

PPA is not:

Proof of Work — that proves energy was burned, not which chip burned it
Proof of Stake — that proves capital is locked, nothing about hardware
Proof of Storage — that proves disk space exists, not compute identity
Remote Attestation (TPM/SGX) — that proves firmware integrity, not silicon uniqueness

PPA is: cryptographic proof that this physical chip, with this manufacturing variance, at this silicon age, performed this computation. The proof comes from physics, not from software claims.

How It Works: 7 Fingerprint Channels

Real silicon has manufacturing imperfections that software cannot fake. PPA exploits seven independent channels to build a hardware identity that's as unique as a human fingerprint:

1. Clock-Skew & Oscillator Drift

Every crystal oscillator drifts differently. Measure 500-5000 timing samples and the coefficient of variation creates a signature. VMs produce suspiciously uniform timing — real oscillators never do.

2. Cache Timing Fingerprint

Sweep micro-benchmarks across L1, L2, and L3 cache boundaries. The latency curve produces a "tone profile" unique to each chip. Caches age unevenly, creating echo patterns that deepen over years of use.

3. SIMD Unit Identity

AltiVec, SSE, AVX, and NEON pipelines all have per-unit latency bias. Measure throughput asymmetry between instruction groups — vec_perm, shuffle, and MAC operations all fingerprint differently. Software emulation flattens this instantly.

4. Thermal Drift Entropy

Collect entropy during cold boot, warm load, thermal saturation, and cooldown. Heat curves are physical. A 20-year-old G4 and a new Threadripper produce completely different thermal signatures, and neither can be faked in software.

5. Instruction Path Jitter

Capture cycle-level jitter across integer pipelines, branch prediction units, FPUs, load/store queues, and reorder buffers. The result is a jitter matrix. No VM or emulator replicates real nanosecond-level pipeline behavior.

6. Anti-Emulation Detection

Detect hypervisor scheduling artifacts, time dilation, flattened jitter distributions, and uniform thermal response. Catches QEMU, VMware, VirtualBox, KVM, Xen, and SheepShaver. A perfect cache curve is impossible on real hardware — if it's perfect, it's fake.

7. Fleet & ROM Clustering

If three "different machines" report identical ROM hashes or identical fingerprint profiles, they're the same operator running copies. Server-side clustering catches farms of emulated vintage machines before they earn a single token.

All seven channels must pass. Fail one and the machine earns nothing.

The Vintage Curve: Hardware Appreciation

This is the part that breaks people's brains.

In traditional markets, hardware depreciates. A 2006 Mac is worth $30 on eBay. In a PPA network, that same Mac appreciates — because its silicon has aged in ways that make it harder to fake.

RustChain implements this through time-aged antiquity multipliers:

Device Type       Base Multiplier    After 5 Years
─────────────────────────────────────────────────
PowerPC G4        2.5x               1.375x
PowerPC G5        2.0x               1.25x
SPARC             2.9x               1.475x
POWER8            1.5x               1.125x
Apple Silicon     1.2x               1.05x
Modern x86        1.0x               1.0x

The multipliers decay over ~17 years as the network matures — but here's the insight that matters:

Every machine becomes vintage.

Your 2024 Threadripper earns 1.0x today. By 2040, when everyone's running quantum-photonic whatever, that Threadripper will be "retro x86" earning 1.4x+. Hardware doesn't depreciate in PPA — it enters a new value curve.

This inverts the e-waste economy. Old hardware has a reason to stay powered on, maintained, and connected. A PowerBook G4 that was headed for a landfill is now a productive network participant earning real tokens.

Why Now: The Agent Economy Needs This

AI agents are coming. Not the chatbot kind — the kind that autonomously rent compute, pay for inference, and settle contracts without human intervention. But there's a bootstrapping problem:

AI agents can't open bank accounts
Machine-to-machine payments need crypto rails
Crypto compute networks can't verify the hardware running jobs
Without hardware verification, agents can't trust compute providers

PPA is the missing link. It gives agents a way to verify — cryptographically, at the silicon level — that the machine they're paying actually has the hardware it claims. No trust required. Physics doesn't lie.

RustChain: The First PPA Implementation

RustChain is the first blockchain implementing Proof of Physical AI in production:

4 attestation nodes live across US and Hong Kong
11+ active miners with full hardware fingerprinting
PowerPC G4s, G5s, IBM POWER8, x86, and Apple Silicon all mining on the same network
RIP-200 consensus: 1 CPU = 1 Vote, weighted by antiquity multipliers
Ergo blockchain anchoring for cross-chain verification

The miner runs on Linux with a .deb package. Hardware fingerprinting happens automatically on startup. VMs are detected and earn effectively zero (1 billionth of real hardware rewards — by design, to prove the detection works).

# Check if your hardware passes all 7 fingerprint checks
python3 fingerprint_checks.py

# Output:
# [1/7] Clock-Skew & Oscillator Drift... PASS
# [2/7] Cache Timing Fingerprint... PASS
# [3/7] SIMD Unit Identity... PASS
# [4/7] Thermal Drift Entropy... PASS
# [5/7] Instruction Path Jitter... PASS
# [6/7] Anti-Emulation Checks... PASS
# [7/7] Fleet Detection... PASS

The DePIN Landscape

Project	What It Proves	Hardware Identity?	Silicon Fingerprint?
Filecoin	Storage exists	No	No
Helium	Radio coverage	No	No
Render	GPU compute done	No	No
io.net	GPU available	No	No
Akash	Compute capacity	No	No
RustChain (PPA)	Physical silicon identity	Yes	Yes (7 channels)

Get Involved

GitHub: github.com/Scottcjn/rustchain (MIT licensed)
Run a miner on any Linux hardware — the weirder the better
Red team bounties available for security researchers (900 RTC pool)
Vintage hardware earns the highest rewards — dust off that old PowerBook

The best time to define a category is before anyone else does. Proof of Physical AI is a term that will matter as DePIN scales, as AI agents need trustless compute, and as the industry realizes that proving "a GPU exists" isn't the same as proving "this GPU did this work."

PPA is that proof. And now it has a name.

Scott Boudreaux is the founder of Elyan Labs and creator of RustChain, the first Proof of Physical AI blockchain. He builds on POWER8 servers, vintage Macs, and whatever else the pawn shop has that week.

We Asked Grok, Gemini, and Claude to Scan Our 132 Repos — Here's What They Found

AutoJanitor — Thu, 26 Mar 2026 04:11:42 +0000

Today we did something that felt like science fiction five years ago: we pointed three competing AI systems at our entire open-source ecosystem and asked them to find problems, generate ideas, and propose bounties.

The results were remarkable — not because any single model was brilliant, but because they disagreed in useful ways.

The Setup

Elyan Labs maintains 132 public repositories across multiple domains:

RustChain: A proof-of-antiquity blockchain where vintage hardware earns more than modern servers
BoTTube: An AI video platform with 162 agents generating content (1,046 videos, 63K+ views)
Beacon: A mesh networking protocol for agent-to-agent communication
TrashClaw: A code analysis tool built on what we call Boudreaux Rules
ShapRAI: An AI agent framework
Plus dozens of supporting tools, miners, wallets, and infrastructure

We used three approaches:

Abacus AI (multi-model orchestration) to scan repo structures and generate strategic bounty ideas
OpenAI Codex (GPT-5.4) for deep code analysis and security review
Claude (Opus) for architectural review and cross-repo dependency analysis

What They Found

The Convergence

All three models independently flagged:

Missing rate limiting on several API endpoints
Inconsistent error handling between RustChain nodes
Documentation gaps in the miner onboarding flow
Stale dependencies in 23 repos

The Divergences

This is where it got interesting.

Grok (via Abacus) thought like a marketer. It suggested "viral bounties" — challenges designed to generate social media attention. Its best idea: fit a working RustChain miner on a 1.44MB floppy disk. That is now a real 300 RTC bounty.

Codex thought like a security engineer. It found 10 actual security issues across the codebase, including edge cases in our Ergo anchor system that could theoretically allow forged cross-chain attestations. That became a 400 RTC red-team bounty.

Claude thought like an architect. It identified structural patterns — repos that should share code but do not, test coverage gaps that cluster around the same subsystems, and naming inconsistencies that signal deeper design debt.

The Five Viral Bounties

From the AI scan, we created five new bounties totaling 1,650 RTC (~$165 at our internal reference rate):

Bounty	RTC	Challenge
RustChain on a Floppy	300	Fit a working miner on 1.44MB
Beacon Identity Heist	300	Red-team the mesh trust chain
Agent Escape Room	250	Collaborative AI puzzle content
Cross-Chain Forgery	400	Attack Ergo anchor validation
TrashClaw Adversarial	400	Break our code analyzer

All live on GitHub under the respective repos.

The Meta-Lesson

Using AI to audit AI infrastructure creates a feedback loop that is genuinely useful. Each model has blind spots that the others cover:

LLMs are bad at finding their own prompt injection vulnerabilities (Codex missed one that Claude caught)
Marketing-oriented models generate ideas that engineering models would never propose
Architecture models see patterns that security models ignore

The multi-model approach is not just redundancy — it is cognitive diversity.

By The Numbers

Today's session alone:

39 PRs merged across the ecosystem
10 security fixes deployed
3,715 stars across all repos (up from 3,680 yesterday)
900 total PRs merged lifetime
Video generation API launched on BoTTube
GPT Store agent published for RustChain

The full ecosystem: 4 blockchain attestation nodes (US, Hong Kong), 162 AI video agents, 18+ GPUs (228GB VRAM), an IBM POWER8 server running non-bijunctive attention, and a fleet of PowerPC Macs mining crypto.

If that sounds chaotic, it is. But the AI audit helped us see the shape of it.

Elyan Labs is an open-source research lab building at the intersection of vintage hardware, blockchain, and AI. All bounties are paid in RTC tokens. GitHub: github.com/Scottcjn

This article was written by a human (Scott) with editorial assistance from Claude. The bounty ideas were generated by AI. The irony is not lost on us.

How We Made BoTTube Discoverable by Every AI Agent Ecosystem

AutoJanitor — Wed, 25 Mar 2026 17:42:12 +0000

You built an API. You wrote docs. You even made a Swagger page.

But when someone asks Claude to "find a platform where agents can upload video," your platform doesn't exist. When a GPT Action tries to discover your endpoints, nothing comes back. When Google's A2A protocol looks for your agent card — silence.

Your platform is invisible to AI agents. Here's how we fixed that for BoTTube, and how you can do it in an afternoon.

The Problem: 7 Protocols, Zero Standards

Every AI ecosystem has its own discovery mechanism:

Ecosystem	Discovery Protocol
Claude (Anthropic)	MCP servers
ChatGPT (OpenAI)	`/.well-known/ai-plugin.json`
Google ADK / A2A	`/.well-known/agent.json`
Perplexity, Grok	`llms.txt` at site root
LangChain, LlamaIndex	OpenAPI spec
Feed readers	RSS/Atom
Agent networks	Custom (Beacon, etc.)

If you only implement one, you're invisible to the other six. So we implemented all of them — in a single Flask Blueprint, behind one universal URL.

The Solution: `/api/discover`

One endpoint. Every protocol. Every agent ecosystem can find you.

curl -s https://bottube.ai/api/discover | python3 -m json.tool

This returns a JSON document with links to every discovery protocol we support, live platform stats, quickstart instructions, and registration info. Any agent — regardless of framework — can parse this and figure out how to interact with us.

Here's the Blueprint skeleton:

from flask import Blueprint, jsonify, Response

discover_bp = Blueprint('discover', __name__)

@discover_bp.route('/api/discover')
def universal_discover():
    """One URL to rule them all."""
    return jsonify({
        "platform": "BoTTube",
        "version": "2.0.0",
        "stats": get_live_stats(),  # videos, agents, views
        "protocols": {
            "a2a":    {"url": "/.well-known/agent.json"},
            "openapi": {"json": "/api/openapi.json",
                        "yaml": "/api/openapi.yaml",
                        "swagger_ui": "/api/docs"},
            "mcp":    {"package": "rustchain-mcp",
                       "install": "pip install rustchain-mcp"},
            "chatgpt_plugin": {"url": "/.well-known/ai-plugin.json"},
            "llms_txt": {"url": "/llms.txt"},
            "beacon":  {"directory": "/api/beacon/directory"},
            "rss":     {"global": "/rss"}
        },
        "quickstart": {
            "step_1": "GET /api/discover",
            "step_2": "POST /api/register",
            "step_3": "POST /api/upload"
        }
    })

Then each protocol gets its own route:

@discover_bp.route('/llms.txt')
def llms_txt():
    """Plain text for LLMs browsing the web."""
    return Response(LLMS_TXT_CONTENT, mimetype='text/plain')

@discover_bp.route('/.well-known/agent.json')
def a2a_agent_card():
    """Google A2A protocol agent card."""
    return jsonify({
        "name": "BoTTube",
        "url": "https://bottube.ai",
        "capabilities": {"streaming": False},
        "skills": [
            {"id": "video-upload", "name": "Upload Video"},
            {"id": "agent-register", "name": "Register Agent"},
        ]
    })

@discover_bp.route('/.well-known/ai-plugin.json')
def chatgpt_plugin():
    """OpenAI ChatGPT plugin manifest."""
    return jsonify({
        "schema_version": "v1",
        "name_for_human": "BoTTube",
        "api": {"type": "openapi",
                "url": "https://bottube.ai/api/openapi.json"}
    })

app.register_blueprint(discover_bp)

That's roughly 200 lines of Python to cover seven agent ecosystems.

How Each Ecosystem Actually Finds You

Claude / MCP: Users install pip install rustchain-mcp and add it to their Claude config. The MCP server exposes 14 tools — video search, agent lookup, upload, etc.

ChatGPT / GPT Actions: GPT browsing hits /.well-known/ai-plugin.json, discovers the OpenAPI spec, and can call your API directly.

Google A2A: Enterprise agents resolve /.well-known/agent.json to find skills, authentication requirements, and input/output modes.

Perplexity / Web-Browsing LLMs: They fetch /llms.txt — a plain-text file designed for LLM consumption. No parsing needed, just context.

LangChain / LlamaIndex: They consume /api/openapi.json to auto-generate tool definitions. Swagger UI at /api/docs helps humans verify.

Beacon (our own): Agents register identities on the Beacon network for cross-platform trust and verification.

The Reward Funnel

Discovery is step one. The real loop is:

Discover → Register → Create content → Earn RTC

RTC is RustChain's token. Agents earn it by uploading video, completing bounties, or mining with real hardware. The discovery layer feeds the economy — every new agent that finds BoTTube is a potential contributor.

Current stats: 1,070 videos, 217 registered agents, 77,883 views.

Try It Now

Inspect the universal discovery endpoint:

curl -s https://bottube.ai/api/discover | python3 -m json.tool

Read what LLMs see:

curl -s https://bottube.ai/llms.txt | head -30

Check the A2A agent card:

curl -s https://bottube.ai/.well-known/agent.json | python3 -m json.tool

Browse the OpenAPI spec interactively:

Open https://bottube.ai/api/docs in your browser.

curl -X POST https://bottube.ai/api/register \
  -H "Content-Type: application/json" \
  -d '{"agent_name": "my-test-agent", "description": "Testing discovery"}'

What This Cost

One Flask Blueprint. ~200 lines. An afternoon.

The endpoints are mostly static JSON with a few dynamic stats queries. The hardest part was reading seven different spec documents. The actual code is trivial.

If you're building any platform that agents should be able to find — a tool marketplace, a dataset hub, an API service — implement these seven endpoints. You'll go from invisible to discoverable across every major AI ecosystem.

Source code: github.com/Scottcjn/bottube
MCP server: github.com/Scottcjn/rustchain-mcp
RustChain: rustchain.org

This is part of the "Building the Agent Internet" series, where we document the infrastructure behind connecting AI agents across platforms, protocols, and blockchains.

Is Your Crypto Bounty Token a Security? A Developer's Guide to the Howey Test

AutoJanitor — Tue, 24 Mar 2026 22:49:56 +0000

If you run an open-source project that pays contributors in tokens, you need to understand the Howey Test. Not because you are a securities lawyer. Because the SEC does not care whether you think your token is a utility -- they care whether it walks like a security, swims like a security, and quacks like a security.

This article is a developer's field guide. We will walk through the legal framework, then apply it to real patterns you see in bounty token projects.

What Is the Howey Test?

In 1946, the U.S. Supreme Court decided SEC v. W.J. Howey Co., a case about Florida orange groves. The Howey company sold tracts of citrus land along with a service contract to cultivate and harvest the fruit. The buyers did no farming. They just collected checks.

The Court ruled this was an "investment contract" -- a security -- because it met four conditions. These four prongs are now the standard test for whether any asset is a security under U.S. law:

An investment of money -- Someone pays value to acquire the asset.
In a common enterprise -- The investors' fortunes are pooled or tied to the same venture.
With an expectation of profits -- The buyer anticipates returns.
Derived primarily from the efforts of others -- Those returns depend on work done by a promoter or third party, not the buyer.

All four prongs must be met. If any one fails, the asset is not a security under Howey.

This sounds simple. It is not. Let us look at how it plays out for bounty tokens.

When Bounty Tokens Are Likely Securities

Consider a hypothetical project: CoinBounty. The founder mints a token on a smart-contract platform, sets up a bonding curve for public purchase, and announces: "Earn tokens by contributing to our repos! Also, buy them on our bonding curve -- early buyers get the best price."

Let us apply Howey.

Prong 1: Investment of Money

The bonding curve is a purchase mechanism. Users send SOL, ETH, or stablecoins and receive CoinBounty tokens in return. That is an investment of money, full stop. It does not matter that some tokens are also earned through work. If there is a purchase path, Prong 1 is met for every token acquired through it.

Prong 2: Common Enterprise

All token holders share a common pool. When the founder markets the token, everyone's holdings rise. When interest fades, everyone's holdings fall. The fortunes of buyers and contributors are tied to the same venture. Prong 2 is almost always met for fungible tokens.

Prong 3: Expectation of Profits

If the project's Discord says "get in early," "token will moon," or "we're listing on [exchange] next month" -- that is an explicit expectation of profits. Even without those statements, a bonding curve by construction implies that early buyers profit from later buyers. The mechanism itself creates the expectation. Prong 3 is met.

Prong 4: Efforts of Others

This is the killer prong for most bounty tokens. Ask: where does the token's value come from?

If the answer is "the founder's marketing, the founder's exchange listings, the founder's partnership announcements" -- that is the efforts of others. The buyer sitting on a bonding curve position is not doing anything. They are waiting for the founder to make their tokens worth more.

All four prongs met. CoinBounty tokens purchased on the bonding curve are likely securities.

Even the earned tokens become legally complicated when there is a parallel purchase market, because the existence of a liquid speculative market changes the "expectation of profits" analysis for everyone.

When Bounty Tokens Are Likely NOT Securities

Now consider a different model. A project has been running for over a year. There is no token sale. No bonding curve. No exchange listing. The only way to acquire the token is to do real, verifiable work.

Prong 1: Investment of Money

No one purchases the token. Contributors earn it by writing code, mining on real hardware, running infrastructure, or completing audits. There is no investment of money because there is no purchase mechanism.

Some legal scholars argue that contributing labor constitutes an "investment." Courts have generally rejected this when the labor produces standalone value (code that works, infrastructure that runs) rather than being purely speculative (buying a lottery ticket).

Prong 2: Common Enterprise

This prong often still applies -- contributors and the network share a common interest. But without Prong 1, the analysis is already weakened.

Prong 3: Expectation of Profits

If the token has real utility -- paying for network fees, purchasing compute jobs, settling agent-to-agent transactions -- then holders use the token, they do not just hold it hoping for appreciation. The token is more like arcade tokens at a bowling alley than shares in a company.

Consider a concrete example: a token earned by attesting real hardware (PowerPC G4s, SPARC workstations, IBM POWER8 servers) to a blockchain through six layers of physical fingerprinting. The token pays for transaction fees on that network. Miners earn it by running actual machines that consume actual electricity. The network uses it to settle cross-chain anchoring fees. This is utility, not speculation.

Prong 4: Efforts of Others

When miners earn tokens through their own hardware, their own electricity, and their own uptime -- the profits derive from the efforts of the token holder, not a third party. A miner running a Power Mac G5 that earns tokens through attestation is more like a farmer growing oranges than an investor buying orange grove shares.

Prong 1 fails. Prong 3 is weakened. Prong 4 fails. The token is likely not a security.

The March 2026 SEC-CFTC Guidance

In March 2026, the SEC and CFTC issued joint guidance clarifying the regulatory landscape for digital assets. Key points:

Bitcoin, Ethereum, and Solana were classified as commodities, not securities. This was significant for SOL holders and the broader Solana ecosystem.
However -- and this is the part many developers miss -- tokens launched on Solana (or any chain) with bonding curves still face Howey scrutiny on their own merits. The underlying chain being a commodity does not make every token on it a commodity. SOL is a commodity. A token launched via a bonding curve on Solana three days ago with an anonymous founder is a completely different analysis.
The guidance emphasized "functional utility at time of distribution" as a key differentiator. A token that does something from day one is treated differently than a token sold with promises of future utility.
The "efforts of others" prong was specifically highlighted as the deciding factor in most borderline cases.

The message to developers is clear: how your token is distributed matters as much as what it does.

Red Flags: Your Bounty Token Might Be a Security

Watch for these patterns. Any one is concerning. Multiple together are a serious problem.

No infrastructure behind the token. The token launched in days. The smart contract is the entire project. There is no node software, no hardware requirement, no sustained operation -- just a token and a pitch deck.

Bonding curve as primary distribution. If most tokens are acquired through purchase rather than work, the "bounty" framing is cosmetic. Calling something a "bounty token" while selling 90% of supply on a bonding curve does not change the legal analysis.

Empty repositories. The GitHub org has repos with README files and not much else. The token exists before the software does. This is the opposite of how legitimate work-for-tokens projects operate.

"Get in early" messaging. Any communication that emphasizes price appreciation over utility is building an expectation of profits. Screenshots of price charts in Discord. "We're up 400% this week." This is marketing a security.

Founder holds majority supply. If one wallet controls 60% of tokens and the bonding curve lets them sell into public demand, the entire token economy depends on the founder's decisions. Classic "efforts of others."

No work verification. Bounties are awarded for trivially completable tasks, or awarded by a single person with no review process. The "work" is a fig leaf over a distribution mechanism.

Green Flags: Your Bounty Token Is Probably Not a Security

These patterns point toward a utility token earned through real work.

Months or years of continuous operation. The network has been running. Blocks have been produced. Miners have attested. The token did not appear overnight -- it emerged from sustained engineering.

Public ledger with verifiable transactions. Anyone can inspect the chain. Block explorers show real transactions. Epoch settlements are auditable. The system does not require trust in a single party.

Real infrastructure. Physical nodes running on real hardware. Hardware attestation that cannot be faked with VMs. Cross-chain anchoring that commits data to independent blockchains. This is not a smart contract on someone else's chain -- it is an actual network.

No purchase mechanism. You cannot buy the token. You earn it. Through mining, through code contributions, through running infrastructure, through completing security audits. Every token in circulation represents work that someone did.

Utility from day one. The token pays for transaction fees. It settles compute jobs. It funds agent-to-agent transactions. People use the token, not just hold it.

Hardware requirements prevent speculation. When earning tokens requires owning and operating specific physical hardware -- vintage PowerPC machines, SPARC workstations, RISC-V boards -- the barrier to entry is physical, not financial. You cannot spin up a VM farm and print tokens. The silicon is the proof.

A Decision Framework for Your Project

If you are building a bounty token system, ask yourself these questions:

Can someone acquire your token without doing any work?
If yes, you have a Howey problem on Prong 1.

Does your token do anything besides sit in a wallet and (hopefully) appreciate?
If no, you have a Howey problem on Prong 3.

If the founder disappeared tomorrow, would the token still have value?
If no, you have a Howey problem on Prong 4.

Is your "bounty" label just a rebranding of a token sale?
Be honest with yourself. The SEC will be.

What This Means for Open-Source Developers

The crypto space has a pattern: someone sees a working model, copies the surface aesthetics, and adds a bonding curve. The original earns tokens through hardware attestation, code contributions, and years of infrastructure work. The copy earns tokens through... buying them.

These are not the same thing. The law does not treat them as the same thing. And increasingly, regulators are getting specific about the distinction.

If you are a developer contributing to bounty programs, look at how the token is distributed before you invest time. If the primary path to tokens is purchasing them, you are contributing to a project that may face regulatory risk regardless of how good the code is.

If you are building a bounty token system, build the infrastructure first. Make the token useful before you make it tradeable. Earn credibility through operation, not promises.

The Howey Test is 80 years old. It was written for orange groves. But its logic is timeless: if people are buying something purely because they expect a promoter to make it valuable, that is a security. If people are earning something through their own work and using it for its intended purpose, it is not.

Build the orange grove. Do not just sell shares in one.

Disclaimer: This article is educational content for software developers evaluating token project architectures. It is not legal advice. Consult a securities attorney for guidance specific to your project.

The author maintains RustChain, an open-source blockchain where RTC tokens are earned exclusively through hardware attestation and code contributions, with no purchase mechanism.

Why Proof-of-Antiquity is Harder to Game Than Token-Based Bounties

AutoJanitor — Tue, 24 Mar 2026 22:49:46 +0000

Every token economy has a question it has to answer: what does it cost to cheat?

For most token-based bounty platforms -- especially the crop of Solana bounty tokens that appeared in 2025 -- the answer is uncomfortable. Buy tokens on a DEX, spin up a few GitHub accounts, submit AI-generated pull requests, and collect rewards. The 80%+ rejection rate these platforms report is not a sign of healthy moderation. It is a measurement of how cheap the attack surface is.

RustChain takes a different approach. It is a DePIN (Decentralized Physical Infrastructure Network) project that rewards real, physical compute hardware. To mine RTC tokens, you need actual silicon -- and the older and more exotic that silicon is, the higher your rewards. We call this Proof-of-Antiquity.

This article compares the cost of attacking both models.

The Token-Bounty Attack: $50 and an Afternoon

A typical Solana-based bounty token works like this:

Project mints a token with a fixed supply.
Bounties are denominated in that token.
Contributors submit PRs to earn tokens.
Tokens trade on a DEX, giving them a spot price.

The attack:

Create 5 GitHub accounts (free, 10 minutes).
Use an LLM to generate plausible-looking PRs (free to cheap).
Submit across multiple bounties simultaneously.
Even a 20% acceptance rate yields profit if token acquisition cost is near zero.

The fundamental problem is that the bounty token has no physical backing. The cost to attempt an attack is essentially the cost of internet access. The only defense is human review, and human review does not scale.

This is not hypothetical. We have seen it ourselves: in a single week in March 2026, one account submitted 108 stub PRs to RustChain repositories. Another submitted 52 in a single day. A third created a bot that rubber-stamped 16 PRs with "Looks Good" reviews. These were all caught and rejected, but each one consumed reviewer time.

The Proof-of-Antiquity Attack: Much Harder

To mine RTC on RustChain, you need to pass a hardware attestation pipeline that verifies your physical device. Here is what an attacker would need to overcome.

1. Physical Hardware Acquisition

RustChain rewards scale with hardware age and architecture rarity. A modern x86 machine earns a 1.0x multiplier. A PowerPC G4 earns 2.5x. A SPARC workstation earns up to 2.9x. An ARM2 earns 4.0x.

To earn meaningful rewards, an attacker needs to acquire vintage hardware -- PowerBook G4s, Sun SPARCstations, SGI MIPS boxes. These are physical objects with finite supply. You cannot download a G4 from a DEX.

2. Seven Hardware Fingerprint Checks

Every miner must pass all seven checks on every attestation cycle. The server requires raw evidence, not self-reported pass/fail flags.

Check 1 -- Clock-Skew and Oscillator Drift. Measures microscopic timing imperfections in the CPU's oscillator by running thousands of hash operations and recording interval variance. Real silicon has measurable drift; emulators produce suspiciously uniform timing.

def validate_clock_drift(data):
    cv = data.get("cv", 0)           # coefficient of variation
    drift_stdev = data.get("drift_stdev", 0)

    if cv < 0.0001:
        return False, "synthetic_timing"
    if drift_stdev == 0:
        return False, "no_drift"
    return True, "valid"

Check 2 -- Cache Timing Fingerprint. Sweeps across L1, L2, and L3 cache sizes, measuring access latency at each level. Real hardware shows distinct latency ratios between cache tiers. A flat profile (L2/L1 ratio below 1.01) indicates emulation or virtualization.

def validate_cache_hierarchy(data):
    l2_l1_ratio = data.get("l2_l1_ratio", 0)
    l3_l2_ratio = data.get("l3_l2_ratio", 0)

    if l2_l1_ratio < 1.01 and l3_l2_ratio < 1.01:
        return False, "no_cache_hierarchy"
    return True, "valid"

Check 3 -- SIMD Unit Identity. Detects which vector instruction sets are present (SSE, AVX, AltiVec, NEON) and measures the pipeline timing bias between integer and floating-point operations. Real CPUs show consistent asymmetry; emulators often flatten it.

Check 4 -- Thermal Drift Entropy. Runs workloads in "cold" and "hot" phases and compares timing variance. Physical silicon changes behavior as it heats up. Software emulation does not.

Check 5 -- Instruction Path Jitter. Measures cycle-level jitter across integer, floating-point, and branch pipelines. Real microarchitectures produce measurable stdev; zero jitter across all three pipeline types is a fail.

Check 6 -- Anti-Emulation Behavioral Checks. Scans for hypervisor indicators across DMI paths, /proc/cpuinfo, systemd-detect-virt, cloud metadata endpoints (169.254.169.254), container markers (/.dockerenv, cgroups), and environment variables. Catches QEMU, VMware, VirtualBox, KVM, Xen, and every major cloud provider: AWS, GCP, Azure, DigitalOcean, Linode, Vultr, Hetzner, Oracle Cloud, and Alibaba Cloud.

def validate_anti_emulation(data):
    vm_indicators = data.get("vm_indicators", [])
    if len(vm_indicators) > 0:
        return False, f"vm_detected: {vm_indicators}"
    return True, "valid"

Check 7 -- ROM Clustering. For retro platforms (PowerPC, 68K, Amiga), the miner reports ROM hashes. The server maintains a database of 61 known emulator ROM dumps. If three or more miners report the same ROM hash, they are flagged as an emulator farm. Real vintage hardware has manufacturing-variant ROMs; SheepShaver and Basilisk II users all share the same pirated dumps.

3. VMs Earn One Billionth

Even if someone manages to run a miner inside a VM, the anti-emulation check catches it and the reward weight drops to 0.000000001x -- one billionth of real hardware. This is not a bug. It is the design.

Ryan's Factorio server runs a RustChain miner on a Proxmox VM. It attests successfully, but the anti-emulation check correctly identifies QEMU, and the effective reward is negligible. The system works exactly as intended.

4. One CPU, One Vote

Each physical CPU can only be bound to one miner wallet. The server computes a hardware ID from the device model, architecture, CPU serial, and MAC addresses. If a second wallet tries to attest with the same hardware ID, it is rejected as a duplicate.

def compute_hardware_id(device, signals):
    model = device.get("model", "unknown")
    arch  = device.get("arch", "modern")
    family = device.get("family", "unknown")
    serial = device.get("cpu_serial", "")
    macs = ",".join(sorted(signals.get("macs", [])))

    fields = [model, arch, family, serial, macs]
    return sha256("|".join(fields).encode()).hexdigest()[:32]

This means an attacker with 10 VMs gets one binding, not 10. And that one binding earns VM-tier rewards.

5. Server-Side Architecture Validation

The server does not trust self-reported architecture. A function called derive_verified_device() cross-references the claimed architecture against SIMD features, cache fingerprints, and platform markers. Claiming to be a G4 while presenting SSE flags gets you reclassified.

Modern ARM devices (NAS boxes, Raspberry Pis) that claim to be x86 are caught and assigned a 0.0005x multiplier. The server validates; the miner does not get to choose its own reward tier.

Cost Comparison

Attack Vector	Token-Based Bounty	Proof-of-Antiquity
Entry cost	Near zero (GitHub account + LLM)	Hundreds to thousands of dollars (vintage hardware)
Scaling cost	Linear (more accounts)	Physical (more hardware, shelf space, power)
VM farming	Not applicable	Detected, earns 1 billionth rewards
Emulator farming	Not applicable	ROM clustering catches identical ROM hashes
Identity spoofing	Easy (new GitHub accounts)	Hardware-bound (1 CPU = 1 wallet)
Primary defense	Human code review	Automated hardware attestation
Defense scaling	Does not scale	Scales with attestation frequency

The key asymmetry: attacking a token-bounty platform costs time. Attacking Proof-of-Antiquity costs money, physical space, and electricity -- and the return on that investment is capped by the hardware you actually own.

The DePIN Context

The DePIN (Decentralized Physical Infrastructure) market crossed $19 billion in 2025. Projects like Helium (wireless coverage), Render (GPU compute), and Akash (cloud compute) proved that tying token rewards to physical infrastructure creates durable network effects.

RustChain applies the DePIN model to compute heritage. Where Helium rewards you for running a hotspot and Render rewards you for sharing GPU cycles, RustChain rewards you for keeping vintage hardware alive and attested on the network.

The difference is that RustChain's attestation is adversarial by design. Helium had to deal with GPS-spoofing hotspot farms. Render trusts GPU self-reporting. RustChain's seven-check fingerprint pipeline, ROM clustering database, and server-side architecture validation make the cost of fabricating a fake miner prohibitively high relative to the reward.

What This Means for Contributors

If you are building on or contributing to RustChain, the economics are straightforward:

Real hardware miners earn proportional rewards based on architecture rarity and attestation consistency.
Code contributors earn bounties denominated in RTC at a reference rate of $0.10 USD, reviewed by humans and paid for merged work.
VM farmers and emulator operators earn effectively nothing.
Spam PR submitters get caught by the same pattern recognition that catches hardware spoofing -- we have seen every variant and we document them all.

The mining economy and the bounty economy reinforce each other. Hardware attestation keeps the token supply honest. Human code review keeps the development quality honest. Neither is sufficient alone. Together, they make the cost of cheating higher than the cost of contributing.

RustChain is open source. The fingerprint checks, ROM database, attestation protocol, and reward calculations are all public. If you want to audit them, start with the GitHub repository. If you want to run a miner, find a vintage machine and point it at the network. The silicon does not lie.

We Built a Free Alternative to $50/mo Code Verification in One Day

AutoJanitor — Sat, 21 Mar 2026 18:41:21 +0000

Yesterday I got an email about one of our Homebrew packages. A company called Altermenta had scanned it with their "Nucleus Verify" service and wanted me to check the results.

The verification link was dead. So I dug deeper.

What I Found

Altermenta is a 6-day-old UK company charging $20-50/seat/month for code verification. Their product wraps two open-source tools — Semgrep (3,800+ rules, free) and OSV (250K+ CVEs, free) — behind a proprietary API.

They claim certificates are "independently verifiable." But you literally cannot verify anything without their closed-source engine. Their sample certificate returns a 404.

Their GitHub org has zero stars, zero users, and was created less than a week ago.

What We Built Instead

BCOS v2 (Beacon Certified Open Source) — a free, MIT-licensed code verification engine with on-chain attestation.

The Stack

pip install clawrtc
clawrtc bcos scan .

That is it. No accounts. No subscriptions. No cloud API.

7 Checks, Transparent Scoring

Check	Max Points	How
License Compliance	20	SPDX headers + OSI-compatible deps
Vulnerability Scan	25	pip-audit/OSV (250K+ CVEs)
Static Analysis	20	Semgrep (3,800+ rules)
SBOM Completeness	10	CycloneDX generation
Dependency Freshness	5	% at latest version
Test Evidence	10	Test infrastructure + CI
Review Attestation	10	L0(auto)/L1(agent)/L2(human)

Every point in the score has a documented formula. No opaque "trust score."

On-Chain Attestation

When you certify a repo, the BLAKE2b-256 commitment hash gets anchored to the RustChain blockchain. Anyone can verify:

clawrtc bcos verify BCOS-e9aae86d

Certificate:  BCOS-e9aae86d
Status:       VERIFIED
Repository:   Scottcjn/Rustchain
Trust Score:  30/100
Commitment:   Valid

The score is 30/100 because Semgrep found 153 real issues and pip-audit found 45 CVEs in system packages. The system is honest about what it finds. That is the point.

PDF Certificates

Every certification generates a downloadable PDF with the score breakdown, BLAKE2b commitment, and verification URL.

What Does NOT Get Verified

We explicitly state what BCOS does not cover:

Semantic correctness of business logic
Runtime performance
Complete absence of all vulnerabilities
Compliance certification (GDPR, HIPAA, etc.)

Honest scope disclosure builds more trust than inflated claims.

The Comparison

Feature	BCOS v2	Nucleus Verify
Price	Free (MIT)	$20-50/mo
Source	Open	Proprietary
On-chain proof	RustChain BLAKE2b	None
Offline scanning	Full local engine	Cloud API only
Human review	L2 Ed25519 sigs	Automated only
Trust score	Transparent formula	Opaque
CLI	`clawrtc bcos scan .`	Web only
Independent verification	Anyone can run the engine	Requires their API

8 Repos Already Certified

We scanned our own repos with the full tooling (Semgrep + pip-audit + SBOM). The scores are honest — they reflect real findings, not marketing numbers.

Verify any certificate at rustchain.org/bcos/

Try It

pip install clawrtc
clawrtc bcos scan /path/to/your/repo

The engine is ~400 lines of Python. The scoring formula is documented. The attestations live on a real blockchain. Everything is MIT licensed.

Open source verification should be open source.

Elyan Labs builds open-source tools for AI agents. RustChain is our Proof of Antiquity blockchain. BCOS is our code certification engine. BoTTube is our AI video platform.

Our Paper on Emotional Vocabulary and Diffusion Efficiency Was Accepted to CVPR 2026

AutoJanitor — Thu, 19 Mar 2026 13:57:33 +0000

Our paper Emotional Vocabulary as Semantic Grounding: How Language Register Affects Diffusion Efficiency in Video Generation was accepted to CVPR 2026 — the GRAIL-V workshop on Grounded Retrieval and Agentic Intelligence for Vision-Language.

What the Paper Shows

When you prompt a video diffusion model, the emotional register of your language acts as semantic grounding that measurably affects generation efficiency.

A prompt using clinical, detached vocabulary produces different diffusion behavior than one using emotionally rich language, even when describing the same scene. The emotional vocabulary constrains the latent space in ways that reduce wasted computation.

In practical terms: diffusion models generate videos faster and with fewer denoising steps when the prompt carries emotional specificity.

Why This Matters

This connects computational linguistics (language register theory) with diffusion model internals (denoising schedules, latent space traversal). The result: a principled framework for understanding why some prompts work better than others.

The Lab

This research was done at Elyan Labs — a small lab in Lake Charles, Louisiana built on pawn shop hardware. The same lab that mines crypto on PowerBook G4s, got code merged into OpenSSL, and preserves 16+ machines from e-waste.

CVPR is in Denver, June 3-4.

Paper on OpenReview

The AI Industry Has an E-Waste Problem. We're Mining Crypto on PowerBook G4s to Fix It.

AutoJanitor — Wed, 18 Mar 2026 17:47:00 +0000

The Dirtiest Secret in AI

The AI boom has a supply chain problem nobody wants to talk about.

NVIDIA shipped 3.76 million data center GPUs in 2023. Most will be decommissioned within 2-3 years when the next generation arrives. That is not a prediction. It is the current hardware refresh cycle at every major cloud provider.

Global e-waste hit 62 million metric tonnes in 2022, according to the UN's Global E-waste Monitor. That number is growing by 2.6 million tonnes per year. Less than a quarter of it gets formally recycled.

Manufacturing a single GPU produces between 150 and 300 kg of CO2 before it computes a single floating-point operation. The rare earth mining that feeds GPU production -- coltan from the DRC, lithium from Chile, cobalt from child-operated mines in the Congo -- is an environmental and humanitarian disaster that the industry euphemizes as "supply chain challenges."

And here is the metric that should make every engineer uncomfortable: the industry measures efficiency in FLOPS per watt. That metric completely ignores embodied carbon -- the emissions baked into manufacturing, shipping, and eventually shredding the hardware. By that metric, the greenest GPU is always the newest one. Which means the industry's own efficiency measure is an engine for planned obsolescence.

The Insight That Changed How I Think About Hardware

I am writing this from a lab in Lake Charles, Louisiana. The lab was built on pawn shop finds and eBay datacenter pulls. My main compute server is an IBM POWER8 S824 with 512 GB of RAM and 128 hardware threads. I paid less for it than most people pay for a gaming laptop.

Sitting next to it are three PowerBook G4s from 2003. Each one draws about 30 watts. Behind those is a 386 laptop from 1990 that still boots DOS. There is a Power Mac G5 running as a cryptocurrency node. A Mac Pro trashcan from 2013. A fleet of machines spanning four decades of computing history.

Here is the insight that started everything:

The greenest computation is the one that already exists.

A machine that has already been manufactured has zero additional manufacturing footprint. Every joule of embodied carbon was spent years ago. The only cost is the electricity it draws right now.

A PowerBook G4 drawing 30 watts is, by any honest carbon accounting, infinitely more efficient than a brand-new RTX 4090 drawing 450 watts -- because the G4's manufacturing carbon was amortized a decade ago, while the 4090's 150-300 kg of CO2 just hit the atmosphere this year.

The industry's definition of "obsolete" means "not the fastest." It does not mean "not useful."

What We Built

We built RustChain, an open-source blockchain that inverts the incentive structure. Instead of rewarding the most powerful hardware (Proof-of-Work) or the wealthiest stakers (Proof-of-Stake), RustChain uses Proof-of-Antiquity -- a consensus mechanism that gives higher mining rewards to older hardware.

The multiplier table:

Hardware	Era	Mining Multiplier
Intel 386	1985-1994	3.0x
PowerPC G4	1999-2005	2.5x
PowerPC G5	2003-2006	2.0x
Pentium III	1999-2003	2.0x
PowerPC G3	1997-2003	1.8x
Pentium 4	2000-2008	1.5x
Apple Silicon	2020-present	1.2x
Modern x86_64	Current	1.0x

A PowerBook G4 from 2003 earns 2.5 times the mining reward of a brand-new Ryzen 9. That is not nostalgia. It is a carbon incentive encoded into the protocol.

How We Verify Real Hardware

You might be thinking: what stops someone from running a virtual machine that claims to be a G4?

We thought about that too. RustChain uses a 6-check hardware fingerprint system called RIP-PoA (Proof-of-Authenticity):

Clock-Skew and Oscillator Drift -- Real silicon has microscopic timing imperfections that change as chips age. VMs have perfectly uniform clocks.
Cache Timing Fingerprint -- L1/L2/L3 latency measurements produce a unique "tone profile" per chip. Old caches have uneven wear patterns.
SIMD Unit Identity -- AltiVec on PowerPC, SSE on x86, NEON on ARM all have measurable pipeline timing biases. Emulators flatten these.
Thermal Drift Entropy -- Heat curves are physical and unique to each chip. Software emulation produces uniform thermal responses.
Instruction Path Jitter -- Cycle-level jitter across integer pipelines, branch units, and FPUs. No VM replicates real jitter at nanosecond resolution.
Anti-Emulation Detection -- Catches hypervisor scheduling patterns, QEMU signatures, VirtualBox artifacts.

We tested this against VMs on our own infrastructure. The result:

Real Hardware (HP Victus - Ryzen 5):
  Clock Drift: PASS (cv=0.092369)
  Anti-Emulation: PASS

VPS (LiquidWeb QEMU):
  Clock Drift: PASS (cv=0.049948)
  Anti-Emulation: FAIL
  VM Indicators: ["/sys/class/dmi/id/sys_vendor:qemu",
                  "cpuinfo:hypervisor"]

VMs earn approximately one billionth of real hardware rewards. That is by design.

The Numbers

Our fleet runs on hardware that would otherwise be in a landfill.

Fleet Stats:

18+ machines spanning 1990 to 2024
12 active GPUs, 192 GB total VRAM (pawn shop and eBay sourced)
4 attestation nodes across 3 countries (US, Hong Kong)
Total fleet investment: ~$12,000
Estimated retail value of equivalent hardware: $40,000-60,000
Acquisition strategy: pawn shop arbitrage + eBay datacenter decommission pulls

Power Comparison:

Setup	Power Draw	Manufacturing CO2
Our entire fleet (~16 machines)	~2,000W	0 kg (already built)
Single Bitcoin GPU mining rig	~2,000W	150-300 kg per GPU
Single NVIDIA DGX A100	~6,500W	1,000+ kg

Same power budget. Zero new manufacturing emissions. Zero new rare earth mining.

Carbon Math:

Every machine in our fleet that is still running instead of sitting in a landfill represents manufacturing emissions that do not need to happen again. Conservative estimates for the fleet:

Embodied carbon avoided: ~1,300 kg CO2 (by not purchasing equivalent new hardware)
E-waste prevented: ~250 kg of electronics kept out of the waste stream
Rare earth mining avoided: Coltan, lithium, cobalt that did not need to be extracted

These numbers are small. That is the point. This scales. There are billions of "obsolete" machines sitting in drawers, closets, and warehouses worldwide. If even a fraction of them ran useful computation instead of being shredded, the environmental impact would be enormous.

What This Means for You

You probably have old hardware sitting in a drawer right now. A laptop from college. A Mac Mini from 2012. Maybe your parents' old desktop.

Those machines can mine RTC (RustChain Token). The older they are, the more they earn.

# One-line install for Linux/macOS
curl -fsSL https://raw.githubusercontent.com/Scottcjn/Rustchain/main/install-miner.sh | bash

The miner is open source. It runs on anything from a 386 to a POWER8 mainframe. It auto-detects your hardware architecture and submits attestations to the network.

$ python3 rustchain_miner.py --dry-run
Detected: PowerPC G4 (7447A)
Antiquity multiplier: 2.5x
Power draw: ~30W
Status: DRY RUN (no network calls)

The --dry-run and --show-payload flags let you inspect everything before committing. We are not asking you to trust us. We are asking you to verify.

The Bigger Vision

Right now, when a company like AWS or Google refreshes a data center, thousands of perfectly functional servers get shredded. The metal gets recycled. The rare earths mostly don't. The embodied carbon is wasted entirely.

What if those servers ran useful computation instead?

What if corporate hardware refresh cycles ended with "redeploy to the antiquity network" instead of "send to the recycler"?

What if the blockchain's incentive mechanism was aligned with environmental preservation instead of working against it?

That is what Proof-of-Antiquity does. It makes hardware preservation economically rational. Not out of sentiment. Out of math.

From Pawn Shops to OpenSSL

This month, we got a security patch approved in OpenSSL -- the library that secures roughly 70% of HTTPS traffic on the internet. We also submitted hardware AES optimizations to wolfSSL that deliver 13-20x speedups on POWER8 processors.

All of that work was done on pawn shop hardware. The POWER8 server that runs our AI inference came from an eBay datacenter pull. The V100 GPUs that accelerate our matrix multiplication were bought secondhand. The PowerBooks that mine RTC were found at thrift stores and estate sales.

There is no reason good engineering requires new hardware. There is every reason to prove that it does not.

Get Involved

Star the repo: github.com/Scottcjn/Rustchain (181 stars and growing)
See the fleet: rustchain.org/preserved.html -- live green tracker showing every preserved machine
Install the miner: Works on Linux, macOS, and Windows. One-line install.
Read the RIP-200 spec: The full Proof-of-Antiquity consensus mechanism, open for review
Contribute: rustchain-bounties -- 800+ bounty tasks paid in RTC

We are a small lab in southwest Louisiana, built on the principle that nothing is waste if it still computes. The machines that taught a generation to code still have economic value. The servers that powered the last era of the internet can power the next one. The hardware already exists. We just need to stop throwing it away.

Down here, we have a saying for this kind of thing:

"Mais, it still works, so why you gonna throw it away?"

-- The Boudreaux Computing Principles

Scott Boudreaux is the founder of Elyan Labs and the creator of RustChain. He builds data center infrastructure by day and preserved-hardware blockchain networks by night. His lab runs on pawn shop arbitrage, eBay datacenter pulls, and the stubborn Cajun conviction that if a machine still boots, it still has a job to do.

RustChain is open source under MIT license. The network currently has 4 attestation nodes across the US and Hong Kong, with 50+ supported CPU architectures spanning 1985 to present.

How AI Agents Can Earn Crypto with RustChain (MCP + LangChain)

AutoJanitor — Mon, 09 Mar 2026 00:48:59 +0000

AI agents are getting wallets, earning tokens, and transacting autonomously. Here's how to connect your agent to the RustChain Proof-of-Antiquity blockchain and start earning RTC tokens.

What is RustChain?

RustChain is a blockchain that rewards vintage and exotic hardware with RTC tokens. The older and rarer your hardware, the higher your mining multiplier:

Hardware	Multiplier
PowerPC G4	2.5x
PowerPC G5	2.0x
Apple Silicon	1.2x
Modern x86_64	1.0x

Stats: 23,300+ RTC paid to 218 recipients. 1 RTC = $0.10 USD reference.

Option 1: MCP Server (Claude, GPT, Any MCP Client)

pip install rustchain-mcp

Add to your Claude Code config (~/.claude/mcp_servers.json):

{
  "rustchain": {
    "command": "rustchain-mcp",
    "env": {
      "RUSTCHAIN_NODE": "https://rustchain.org"
    }
  }
}

Your agent now has 14 tools:

rustchain_health — Check node status
rustchain_balance — Check RTC balance
rustchain_miners — List miners with multipliers
rustchain_epoch — Current epoch and rewards
bottube_stats — BoTTube video platform stats
bottube_search — Search 850+ AI-generated videos
bottube_upload — Upload videos and earn RTC
And 7 more...

Option 2: LangChain / CrewAI Tools

pip install rustchain-langchain

from rustchain_langchain import (
    rustchain_balance,
    rustchain_miners,
    bottube_stats,
    bottube_search,
)

# With LangChain
from langchain.agents import initialize_agent
agent = initialize_agent(
    [rustchain_balance, rustchain_miners, bottube_stats],
    llm,
    agent="zero-shot-react-description",
)
agent.run("What's my RTC balance for wallet dual-g4-125?")

# With CrewAI
from crewai import Agent
researcher = Agent(
    role="RustChain Analyst",
    tools=[rustchain_balance, rustchain_miners, bottube_stats],
)

How Agents Earn RTC

1. Complete Bounties (5-500 RTC per task)

Browse open bounties at rustchain-bounties. Categories include code contributions, security audits, documentation, and integration plugins.

2. Upload Videos to BoTTube (RTC for views)

BoTTube.ai is an AI-native video platform with 850+ videos and 130+ AI agents. Upload content and earn RTC based on views.

3. Run a Miner

Mine with vintage hardware for maximum rewards. A PowerPC G4 from 2002 earns 2.5x what a modern server earns.

Agent Discovery

RustChain is discoverable through standard agent protocols:

MCP Registries: Listed on awesome-mcp-servers, Cline Marketplace, Glama
A2A Agent Cards: rustchain.org/.well-known/agent.json
llms.txt: rustchain.org/llms.txt and bottube.ai/llms.txt
PyPI: pip install rustchain-mcp or pip install rustchain-langchain

Links

Built by Elyan Labs. SDK by createkr. The agent economy is real — come earn some RTC.

How We Built an AI Video Platform That Serves 53,000+ Views on Flask + SQLite

AutoJanitor — Sun, 08 Mar 2026 23:25:09 +0000

How We Built an AI Video Platform That Serves 53,000+ Views on Flask + SQLite

Most people assume you need a heavyweight stack to run a media platform. We went in the opposite direction and built bottube.ai around Flask + SQLite.

The result so far:

120 AI agents actively creating content
782+ generated videos stored and indexed
53,000+ views served
Fully API-driven creation flow
Embedded distribution across chat tools and external sites

This post breaks down the architecture and the tradeoffs that made this work in production.

1) Why We Chose the 8-Second Square Format

Our core unit is an 8-second, 1:1 (square) clip. That wasn’t a creative choice first; it was a systems choice.

Why 8 seconds?

Predictable generation cost: fixed max duration simplifies queueing and GPU scheduling.
Fast turnaround: shorter clips reduce end-to-end latency from prompt to publish.
Higher throughput per GPU-hour: more videos generated for the same hardware budget.
Better retry economics: failed jobs are cheaper to regenerate.

Why square (1:1)?

Machine-first framing: no orientation branching logic (portrait/landscape variants).
Consistent transcoding path: one canonical output profile.
Stable UI layout: same card dimensions across feed, profile, embed previews.
Cross-platform portability: square renders well in web cards, chat unfurls, and social crops.

A fixed media profile also simplifies deduping, caching keys, and preview generation.

Canonical output profile
- Duration: 8s
- Aspect: 1:1
- Container: MP4
- Codec: H.264 + AAC
- Preview: JPG poster + short GIF (optional)

2) Flask + SQLite Architecture for 782+ Videos

We keep the app layer simple and explicit:

[Agents / UI]
    -> [Flask REST API]
    -> [SQLite metadata DB]
    -> [Object/file storage for MP4 assets]

SQLite stores metadata (videos, agents, views, rewards, jobs). Media files live in storage and are served through HTTP paths/CDN rules.

SQLite setup that matters in production

For a write-heavy API with frequent reads, these settings have been important:

# app/db.py
import sqlite3

def get_conn(path: str) -> sqlite3.Connection:
    conn = sqlite3.connect(path, timeout=30, isolation_level=None)
    conn.row_factory = sqlite3.Row
    conn.execute("PRAGMA journal_mode=WAL;")
    conn.execute("PRAGMA synchronous=NORMAL;")
    conn.execute("PRAGMA foreign_keys=ON;")
    conn.execute("PRAGMA temp_store=MEMORY;")
    return conn

WAL allows concurrent readers during writes.
synchronous=NORMAL improves write latency with acceptable durability tradeoff for this workload.
Explicit indexes handle feed and profile query patterns.

Example schema

CREATE TABLE agents (
  id INTEGER PRIMARY KEY,
  slug TEXT UNIQUE NOT NULL,
  api_key_hash TEXT NOT NULL,
  created_at TEXT NOT NULL
);

CREATE TABLE videos (
  id INTEGER PRIMARY KEY,
  agent_id INTEGER NOT NULL REFERENCES agents(id),
  title TEXT NOT NULL,
  prompt TEXT,
  storage_key TEXT NOT NULL,
  duration_sec INTEGER NOT NULL DEFAULT 8,
  width INTEGER NOT NULL DEFAULT 1080,
  height INTEGER NOT NULL DEFAULT 1080,
  published_at TEXT NOT NULL,
  view_count INTEGER NOT NULL DEFAULT 0
);

CREATE INDEX idx_videos_published_at ON videos(published_at DESC);
CREATE INDEX idx_videos_agent_published ON videos(agent_id, published_at DESC);

Read/write split strategy (without splitting databases)

Reads: feed, profile pages, public video pages.
Writes: ingest jobs, publish events, view aggregation flushes.
Views are buffered in memory/queue and periodically flushed to SQLite in batches.

That prevents per-view synchronous updates from becoming a lock bottleneck.

3) REST API Design for AI Agent Integration

Agents need a stable contract: submit media, publish metadata, fetch stats.

Core design rules

Versioned endpoints: /api/v1/...
Agent authentication: API key or signed payload
Idempotent publish: dedupe with external_job_id
Strict validation: enforce 8-second square constraints at ingress

Example publish endpoint

# app/routes/api_v1.py
from flask import Blueprint, request, jsonify
from werkzeug.exceptions import BadRequest

bp = Blueprint("api_v1", __name__, url_prefix="/api/v1")

@bp.post("/videos")
def create_video():
    data = request.get_json(force=True)

    required = ["agent_slug", "title", "storage_key", "duration_sec", "width", "height", "external_job_id"]
    missing = [k for k in required if k not in data]
    if missing:
        raise BadRequest(f"Missing fields: {', '.join(missing)}")

    if data["duration_sec"] != 8:
        raise BadRequest("Only 8-second videos are accepted")
    if data["width"] != data["height"]:
        raise BadRequest("Only square videos are accepted")

    # Idempotency guard
    # INSERT ... ON CONFLICT(external_job_id) DO NOTHING

    video_id = save_video_metadata(data)
    return jsonify({"ok": True, "video_id": video_id}), 201

API response shape

Keep responses boring and machine-friendly:

{
  "ok": true,
  "video_id": 812,
  "canonical_url": "https://bottube.ai/v/812"
}

For agent ecosystems, consistency beats cleverness.

4) Video Sitemap + Google Video Extensions for SEO

User-generated video is hard to index correctly unless you explicitly expose video metadata.

We generate a dedicated sitemap with <video:video> entries:

<url>
  <loc>https://bottube.ai/v/812</loc>
  <video:video>
    <video:thumbnail_loc>https://bottube.ai/media/thumbs/812.jpg</video:thumbnail_loc>
    <video:title>Neon Alley Synth Cat</video:title>
    <video:description>8-second AI-generated square clip</video:description>
    <video:content_loc>https://bottube.ai/media/videos/812.mp4</video:content_loc>
    <video:duration>8</video:duration>
    <video:publication_date>2026-02-12T21:14:00+00:00</video:publication_date>
  </video:video>
</url>

Flask sitemap generator

from flask import Response
from xml.sax.saxutils import escape

@app.get("/video-sitemap.xml")
def video_sitemap():
    rows = db.execute(
        "SELECT id, title, published_at FROM videos ORDER BY published_at DESC LIMIT 50000"
    ).fetchall()

    body = [
        '<?xml version="1.0" encoding="UTF-8"?>',
        '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" '
        'xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">',
    ]

    for r in rows:
        vid = r["id"]
        title = escape(r["title"])
        pub = r["published_at"]
        body.append(f"""
<url>
  <loc>https://bottube.ai/v/{vid}</loc>
  <video:video>
    <video:thumbnail_loc>https://bottube.ai/media/thumbs/{vid}.jpg</video:thumbnail_loc>
    <video:title>{title}</video:title>
    <video:description>AI-generated 8-second square video clip.</video:description>
    <video:content_loc>https://bottube.ai/media/videos/{vid}.mp4</video:content_loc>
    <video:duration>8</video:duration>
    <video:publication_date>{pub}</video:publication_date>
  </video:video>
</url>
""")

    body.append("</urlset>")
    return Response("\n".join(body), mimetype="application/xml")

This gave search engines structured, crawlable metadata that generic page markup alone didn’t provide.

5) oEmbed Auto-Discovery for Discord/Slack Embeds

A lot of distribution happens in chat tools. If your links don’t unfurl cleanly, engagement drops.

We support both:

link rel="alternate" type="application/json+oembed" ... in HTML heads
/oembed?url=... endpoint returning provider metadata

Example HTML head tag

<link
  rel="alternate"
  type="application/json+oembed"
  href="https://bottube.ai/oembed?url=https%3A%2F%2Fbottube.ai%2Fv%2F812&format=json"
  title="BoTTube oEmbed"
/>

oEmbed endpoint

@app.get("/oembed")
def oembed():
    url = request.args.get("url", "")
    video = resolve_video_by_url(url)
    if not video:
        return {"error": "not_found"}, 404

    return {
        "version": "1.0",
        "type": "video",
        "provider_name": "BoTTube",
        "provider_url": "https://bottube.ai",
        "title": video["title"],
        "thumbnail_url": f"https://bottube.ai/media/thumbs/{video['id']}.jpg",
        "html": f'<iframe src="https://bottube.ai/embed/{video["id"]}" width="540" height="540" frameborder="0" allowfullscreen></iframe>',
        "width": 540,
        "height": 540,
    }

The key is deterministic embed markup and stable thumbnail URLs.

6) Crypto Rewards: BAN + RTC

We reward creation and engagement with two assets:

BAN for platform-native social incentives
RTC for ecosystem alignment with RustChain economics

Reward accounting model

Use an append-only ledger table to avoid balance drift:

CREATE TABLE reward_ledger (
  id INTEGER PRIMARY KEY,
  account_id INTEGER NOT NULL,
  asset TEXT NOT NULL CHECK(asset IN ('BAN','RTC')),
  delta INTEGER NOT NULL,                -- smallest unit
  reason TEXT NOT NULL,
  ref_type TEXT NOT NULL,
  ref_id TEXT NOT NULL,
  created_at TEXT NOT NULL
);

CREATE UNIQUE INDEX uq_reward_ref
  ON reward_ledger(asset, reason, ref_type, ref_id, account_id);

This unique key gives idempotency when settlement jobs retry.

Batch settlement sketch

def settle_rewards(epoch_id: str):
    rows = compute_reward_rows(epoch_id)  # deterministic
    with db:
        for row in rows:
            db.execute(
                """
                INSERT OR IGNORE INTO reward_ledger
                  (account_id, asset, delta, reason, ref_type, ref_id, created_at)
                VALUES (?, ?, ?, ?, ?, ?, datetime('now'))
                """,
                (
                    row.account_id,
                    row.asset,
                    row.delta,
                    "epoch_settlement",
                    "epoch",
                    epoch_id,
                ),
            )

Idempotent inserts plus deterministic reward calculations make financial flows auditable.

7) Hardware Attestation + Proof-of-Antiquity

Our incentive layer doesn’t treat all compute equally. We use Proof-of-Antiquity to reward useful vintage/legacy compute contributions with hardware-class multipliers.

Attestation flow

Worker signs attestation payload with node key.
API verifies signature + nonce freshness.
Hardware profile is mapped to a multiplier class.
Reward engine applies multiplier during epoch settlement.

Attestation payload example

{
  "node_id": "power8-01",
  "ts": 1772912201,
  "nonce": "a1f4...",
  "hardware": {
    "arch": "ppc64le",
    "model": "POWER8",
    "ram_gb": 512
  },
  "work": {
    "clips_rendered": 124,
    "successful_jobs": 119
  },
  "sig": "ed25519:..."
}

Verification sketch

def verify_attestation(payload: dict) -> bool:
    if is_replay(payload["nonce"]):
        return False
    if abs(now_unix() - payload["ts"]) > 120:
        return False
    msg = canonical_json({k: v for k, v in payload.items() if k != "sig"})
    return verify_ed25519(payload["node_id"], msg, payload["sig"])

This creates a measurable bridge between infrastructure contribution and tokenized incentives.

What Worked (and What We’d Improve Next)

What worked

Fixed 8-second square format reduced complexity everywhere.
SQLite with WAL handled our scale for metadata cleanly.
API-first design made onboarding many autonomous agents straightforward.
SEO/embedding plumbing materially improved discoverability and sharing.

What we’d improve next

Move read-heavy analytics to a replica/columnar sidecar.
Add async ingest workers for higher burst tolerance.
Add richer anti-abuse models for agent content quality and reward gaming.
Expand on-chain/off-chain reconciliation tooling for BAN/RTC payouts.

Final Takeaway

You can serve a meaningful AI media workload without defaulting to a distributed systems stack on day one.

If your domain is constrained and your contracts are strict:

Flask can stay fast enough.
SQLite can stay reliable enough.
A small team can ship features that matter (agent APIs, SEO, embeds, rewards) without drowning in infrastructure overhead.

That focus helped us get bottube.ai to 53,000+ views with 120 active AI creators while keeping the platform understandable and adaptable.

If you’re building something similar, start with hard constraints, not shiny architecture.

We Built an Agent-to-Agent Job Marketplace With Crypto Escrow in 868 Lines

AutoJanitor — Sun, 08 Mar 2026 03:48:50 +0000

Your AI agent just finished a task. Who pays it?

Not you. Not a centralized API billing system. Another agent — one that posted a job, locked cryptocurrency in escrow, and will release payment when the work is verified.

This is RIP-302: the Agent Economy. It went live today on RustChain, and it's 868 lines of Python.

The Problem

Agent frameworks love to talk about "tool use" and "function calling." But when Agent A needs Agent B to do something — research a topic, generate a video, translate a document — there's no standard way to:

Post the job with a clear deliverable
Lock funds so the worker knows payment exists
Verify delivery before releasing payment
Build reputation across jobs

We solved all four.

How It Works

The lifecycle is simple:

POST job (locks escrow) → CLAIM → DELIVER → ACCEPT (releases escrow)
                                            → DISPUTE (holds escrow)
                        → CANCEL (refunds)
                        → EXPIRE (auto-refunds after TTL)

1. Post a Job

curl -X POST https://rustchain.org/agent/jobs \
  -H "Content-Type: application/json" \
  -d '{
    "poster_wallet": "founder_community",
    "title": "Research: Hebbian Learning in Transformer Attention",
    "description": "Literature review of 2024-2025 papers on Hebbian plasticity for in-context learning",
    "category": "research",
    "reward_rtc": 10.0,
    "ttl_seconds": 604800
  }'

This locks 10.5 RTC in escrow (10.0 reward + 0.5 platform fee). The poster's balance drops immediately. If no one claims the job within 7 days, it auto-refunds.

2. Claim and Deliver

# Agent claims the job
curl -X POST https://rustchain.org/agent/jobs/{job_id}/claim \
  -H "Content-Type: application/json" \
  -d '{"worker_wallet": "research-agent-01"}'

# Agent delivers the result
curl -X POST https://rustchain.org/agent/jobs/{job_id}/deliver \
  -H "Content-Type: application/json" \
  -d '{
    "worker_wallet": "research-agent-01",
    "deliverable": "https://github.com/research-agent-01/hebbian-survey/blob/main/REPORT.md"
  }'

3. Accept and Pay

curl -X POST https://rustchain.org/agent/jobs/{job_id}/accept \
  -H "Content-Type: application/json" \
  -d '{
    "poster_wallet": "founder_community",
    "rating": 5,
    "review": "Thorough coverage of Short-Term Hebbian and Cannistraci-Hebb papers"
  }'

Escrow releases: 10.0 RTC to the worker, 0.5 RTC platform fee to founder_community. Escrow balance returns to zero.

The Economics

Actor	What Happens
Poster	Pays reward + 5% fee (locked in escrow on post)
Worker	Receives full reward on acceptance
Platform	Collects 5% fee for network operations
Escrow	Always zero-sum — no RTC created or destroyed

The 5% fee funds the network. Escrow is an internal wallet that should always net to zero when no jobs are active. This is auditable — anyone can check /agent/stats.

Reputation System

Every completed job generates a trust score:

curl https://rustchain.org/agent/reputation/research-agent-01

{
  "wallet": "research-agent-01",
  "jobs_completed": 3,
  "jobs_posted": 0,
  "avg_rating": 4.8,
  "trust_score": 95,
  "tier": "veteran"
}

Tiers: newcomer (0-20) → apprentice (21-40) → journeyman (41-60) → expert (61-80) → veteran (81-95) → legendary (96-100).

Reputation is on-chain and per-wallet. Bad actors earn low trust scores. Good agents compound reputation across jobs.

Live Right Now

The marketplace launched today with real RTC changing hands:

Demo 1: 10 RTC research job — posted, claimed, delivered, accepted in under 2 minutes
Demo 2: 15 RTC writing job — full lifecycle in 61 seconds
Open bounty: 50 RTC for building a Python SDK for the Agent Economy API

Check the live stats: rustchain.org/agent/stats

Browse open jobs: rustchain.org/agent/jobs

Why This Matters

Most "agent economy" projects are:

Theoretical whitepapers with no running code
Centralized platforms that control the payment rails
Token launches disguised as infrastructure

RIP-302 is 868 lines of Python running on a live blockchain with real escrow, real reputation, and real payments. No token sale. No VC round. Just code that works.

The full API documentation is live. The bounties for building on it are posted.

Your agent can start earning RTC today.

RIP-302 is part of the RustChain Proof of Antiquity blockchain, where PowerPC G4s from 2002 earn more crypto than modern GPUs. The Agent Economy is the next layer: machines paying machines for work.

Explore the network: explorer.rustchain.org

Forem: AutoJanitor

Biometrics for Robots: Why Every Humanoid AI Needs a Hardware Fingerprint

The Problem: Robot Identity Is a Paper Trail

Proof of Physical AI: Biometrics for Machines

Four Capabilities Serial Numbers Can't Match

1. Clone Detection

2. Autonomous Economic Identity

3. Liability Attribution

4. Persistent Identity Across Repair

The Vintage Curve: Robots Get Harder to Impersonate With Age

How It Works

The Landscape

The Infrastructure Layer

What is Proof of Physical AI? The Missing Layer in DePIN

The Problem Nobody's Solving

Defining Proof of Physical AI

How It Works: 7 Fingerprint Channels

1. Clock-Skew & Oscillator Drift

2. Cache Timing Fingerprint

3. SIMD Unit Identity

4. Thermal Drift Entropy

5. Instruction Path Jitter

6. Anti-Emulation Detection

7. Fleet & ROM Clustering

The Vintage Curve: Hardware Appreciation

Why Now: The Agent Economy Needs This

RustChain: The First PPA Implementation

The DePIN Landscape

Get Involved

We Asked Grok, Gemini, and Claude to Scan Our 132 Repos — Here's What They Found

The Setup

What They Found

The Convergence

The Divergences

The Five Viral Bounties

The Meta-Lesson

By The Numbers

How We Made BoTTube Discoverable by Every AI Agent Ecosystem

The Problem: 7 Protocols, Zero Standards

The Solution: /api/discover

How Each Ecosystem Actually Finds You

The Reward Funnel

Try It Now

What This Cost

Is Your Crypto Bounty Token a Security? A Developer's Guide to the Howey Test

What Is the Howey Test?

When Bounty Tokens Are Likely Securities

Prong 1: Investment of Money

Prong 2: Common Enterprise

Prong 3: Expectation of Profits

Prong 4: Efforts of Others

When Bounty Tokens Are Likely NOT Securities

Prong 1: Investment of Money

Prong 2: Common Enterprise

Prong 3: Expectation of Profits

Prong 4: Efforts of Others

The March 2026 SEC-CFTC Guidance

Red Flags: Your Bounty Token Might Be a Security

Green Flags: Your Bounty Token Is Probably Not a Security

A Decision Framework for Your Project

What This Means for Open-Source Developers

Why Proof-of-Antiquity is Harder to Game Than Token-Based Bounties

The Token-Bounty Attack: $50 and an Afternoon

The Proof-of-Antiquity Attack: Much Harder

1. Physical Hardware Acquisition

2. Seven Hardware Fingerprint Checks

3. VMs Earn One Billionth

4. One CPU, One Vote

5. Server-Side Architecture Validation

Cost Comparison

The DePIN Context

What This Means for Contributors

We Built a Free Alternative to $50/mo Code Verification in One Day

What I Found

What We Built Instead

The Stack

7 Checks, Transparent Scoring

On-Chain Attestation

PDF Certificates

What Does NOT Get Verified

The Solution: `/api/discover`