litepaper · v1 · 2026-05

wrkr litepaper.

Substrate, beachhead, token, mechanism.

The full thesis: the substrate that hosts AI coding agents shipping multi-tenant SaaS, why crypto-projects-on-Base is the beachhead, the $WRKR community alignment token, the Bracket coordination service, and the burn mechanism that ties it together.

chapter I

Why now

The next trillion users on the internet will not be people. They will be AI coding agents — OpenCode, Claude Code, Codex CLI, Gemini CLI — running real software work on behalf of human operators. Every major category of software was designed for humans clicking buttons. None of it was rebuilt for agents as first-class citizens.

Frontier coding models are already good enough to ship working multi-tenant SaaS end-to-end. The bottleneck is the substrate they run on. Today's agent runtimes put agents in ephemeral sandboxes — preview environments that can't run cron, hold state, or serve traffic to paying customers.

wrkr is the persistent Linux substrate that closes the gap. The agent lives on the production machine — same Firecracker microVM that runs the served webapp, the worker queue, the cron jobs, the persistent disk, the deploy lane. The agent is the operator's primary interface, with the substrate's capabilities as native primitives.

chapter II

The substrate

Every operator gets a dedicated Firecracker microVM — the same KVM-based isolation tech AWS Lambda runs on — with a persistent ext4 disk archived to S3 at rest, sub-second resume from idle, and an AI coding harness pre-attached to a browser PTY.

The workspace surfaces four substrate tabs: Terminal (the agent's native TUI), Files (artifact browser with image / PDF / sheet preview), Preview (the operator's served webapp at a slug-routed URL, with a Comment / Edit / Annotate workbench layered over the iframe), and Browser (VM Chrome via KasmVNC with persistent tenant cookies and signed CDP for harness automation, including 2FA handoff to the operator).

Around the workspace: a multi-unit deploy lane (web + private worker + cron + storage as one declared release group), slug-routed public URLs, per-tenant custom-domain projection, immutable releases with candidate-then-promote, VM-global secrets vault, and a credential-owner sidecar that hot-switches between BYOM and managed LLM provider keys.

Billing rail: x402 + EIP-3009 USDC on Base. Plan subscriptions and Bracket pool fees both settle on-chain. Managed LLM credits pass through at provider cost.

chapter III

The operator

The wrkr operator is a builder who knows what to build and why, and uses an AI coding harness as the how. Solo founders, marketers, and domain experts who run their own ops platform without hiring a developer.

This is the segment AI coding harnesses unlocked between 2024 and 2026. Lovable, Bolt, v0 served the visual builder side; Cursor, Claude Code, OpenCode served the terminal-native side. wrkr serves the substrate side — the persistent Linux machine where these harnesses graduate from preview environments to production runtimes shipping multi-tenant SaaS to paying customers.

The operator profile is observable across the segment today: solo or small teams running multi-tenant deliveries, AI coding harness as the technical execution loop, shipping in days rather than months. The substrate is shaped to that profile because that is the segment most exposed to the orchestration tax substrate primitives remove.

chapter IV

The beachhead

The beachhead is crypto projects on Base. The segment has the highest concentration of operator pain the substrate primitives remove: every token launch needs custom Telegram bots, dashboards, leaderboards, and small SaaS surfaces, currently shipped one-off across nine vendors. Treasury budget to spend, vocal feedback loop on Crypto Twitter, channel concentration on CT and Farcaster, and on-chain-verifiable validation through USDC payment flows.

The expansion path beyond the beachhead: indie hackers and AI-native agencies, then vertical-SaaS operators in regulated industries. Average ARPU shifts up as operators run more customer tenants per VM.

The TAM: every multi-tenant SaaS operator globally, currently served by a 9-vendor stack. wrkr collapses that to one bill. Cloudflare's developer-platform revenue is the conservative comparable.

chapter V

The token

$WRKR is the community alignment token. Fair-launch on Clanker (Base) as a standard ERC-20 with no admin keys, no transfer hook, and an LP permanently locked in Clanker's locker contract. Once the contract deploys, $WRKR is sovereign — the supply is fixed, the LP is locked, the burn address is verifiable on Base.

Alignment runs through the burn loop: substrate revenue settles in USDC, USDC buys $WRKR off the open market, $WRKR ships to a burn address. The supply curve tracks the substrate's revenue curve.

See /tokenomics for token basics, distribution, and the full fee structure.

chapter VI

The coordination service

Bracket is the launch-coordination service for projects that ship product on the substrate first. Mechanism: a dual-track ETH pool. The project's own dev contributes from their wallet (no $WRKR required); $WRKR holders above the tier threshold contribute separately. Both tracks combine into one atomic first-buy at deploy via Clanker SDK — guaranteed in the same transaction as the token deploy. Pro-rata distribution to every contributor. 1% of pooled ETH is the coordination fee, routed into the burn loop.

PROJECT

built on wrkr · dev can commit ETH

Product already shipped. Launches token on Clanker. Optional: dev commits own ETH to the Bracket pool — no $WRKR needed.

+ dev ETH (optional)
[ ]

BRACKET

first buyer · 1% of pooled ETH

Pools Dev ETH + Cult ETH. Executes the native dev-buy slot transaction. Distributes tokens pro-rata to every contributor.

+ cult ETH

$WRKR CULT

pledged ETH · tier ≥ Basic

The cult = $WRKR holders. They pool ETH from many wallets during the commitment window.

1%Wrkr's cut · of pooled ETH

Stays with wrkr → buyback & burn $WRKR

Wrkr never holds project tokens or asks the project for an allocation. We only execute the first buy and collect a small ETH fee. More Bracket activity → more burns → more $WRKR value.

// example · dev + cult

  1. 1. Project X ships its product on wrkr. Plans to launch $X on Clanker at time T.
  2. 2. Wrkr opens a Bracket window. Two tracks contribute:
    • 2 ETH from Project X's own dev (dev track)
    • 3 ETH from $WRKR holders across many wallets (cult track)
    • Combined pool: 5 ETH
  3. 3. At time T (in the native dev-buy slot): wrkr submits a 4.95 ETH buy on $X — first transaction on the new pool.
  4. 4. $X received → distributed pro-rata across every contributor:
    • Dev gets 40% of $X (contributed 2/5 of the pool)
    • Cult holders share 60% pro-rata to their individual pledges
  5. 5. 0.05 ETH (the 1% cut) → wrkr buys & burns $WRKR.

No reserves. No allocations. Dev and cult both pledge, both eat from the same buy.

Bracket activates after the project's product is live with paying customers. The coordination layer wraps Clanker's native dev-buy slot so the first transaction on the new pool is one combined atomic buy.

See /bracket for dual-track rules, control matrix, sniper-fee window, and the trade-off table.

chapter VII

The burn mechanism

Every quarter, all net profit goes to buying $WRKR off the open market on Base. Bought $WRKR ships to a verifiable burn address. The supply curve tracks the substrate's revenue curve, on a fixed cadence, in public.

Burns are quarterly events with countdown, announcement, and execution — visible cadence aligns the community with substrate performance.

The calculation is straightforward: revenue inputs (plan subscriptions in USDC, Bracket coordination fees in ETH when it ships) minus operating costs (infra, LLM passthrough at provider cost, salary, marketing) = net profit. 100% of net profit funds the buyback. Same calculation every quarter.

chapter VIII

Honest unknowns

Beachhead compression. If the crypto-projects-on-Base segment slows, the beachhead pace slows with it. The substrate is rail-agnostic — operators shipping multi-tenant SaaS exist in every segment, and expansion paths (indie hackers, agencies, vertical-SaaS) don't require a rebuild. The TAM is operators, not crypto.

Substrate competition. Replit, Vercel, Render, and incumbents could rebuild the substrate. The architectural decisions for the serve layer have to be made on day one — multi-tenant Firecracker isolation, per-user persistent disk, deploy lane separate from preview, slug-based public URL routing, idle-freeze with traffic-driven resume, archive-and-rehydrate to S3. Retrofitting onto a stateless container framework is a multi-quarter rewrite.

Token launch timing. $WRKR launches when it's ready, announced at launch, not before. The launch is the on-chain validation engine — once live, anyone can verify shipped products at slug URLs, USDC payment flows on Base, and creator-fee accrual on Clanker.

Bracket scaling. The first Bracket events set tier thresholds, refine commitment-window mechanics, and tune the dev/community track ratio. Some details (exact tier sizes, window duration, scheduling cadence) are calibrated against the first few launches rather than committed in advance.

chapter IX

Roadmap

Phase 0 — Foundation. Done. Substrate live and self-serve, multi-tenant deploy lane operational, USDC billing rail wired.

Phase 1 — Token launch. $WRKR fair-launch on Clanker (Base). Distribution finalized at deploy. Creator fees start accruing immediately. Announced at launch, not before.

Phase 2 — Community formation. Telegram opens. $WRKR holder community forms around the public roadmap and burn cadence. CT amplification of operator-shipped products.

Phase 3 — First Bracket event. First substrate-shipped project launches its own token via Bracket coordination — dual-track pool, atomic first-buy, pro-rata distribution. On-chain validation of the coordination flow.

Phase 4 — First quarterly burn. First quarterly buyback-and-burn from net profit. Public on-chain report. Cadence locked from this point forward.

Phase 5 — Expansion segments. Indie hackers, AI-native agencies, and vertical-SaaS operators come online as reach expands beyond the beachhead. Substrate stays rail-agnostic.

Phase 6 — Vertical-SaaS layer. Vertical operators in regulated industries — higher ARPU, sticky retention, sales-led + content-led GTM.

Execution pace is fast. The token launch and the substrate's public visibility are mutually reinforcing — every shipped feature is verifiable on-chain.

closing

The substrate is the moat.

Real Linux. Real revenue. Real burns.

Everything in this document is shipped, shipping, or scheduled. The substrate is live. The token launches when it's ready. The first burn happens at the first quarter close. The roadmap is the actual work.