~/blog/hello-world

This is the first post on the cocore blog. It'll be one of the only ones for a while.

cocore is our first attempt at a shared compute environment on top of the AT Protocol. It's heavily influenced by two pieces of writing that showed up at the right moment:

• cocore: Airbnb for compute on Silicon Florist — which is actually our own writing from a few years back, when we were toying with the idea of a cloud co-op for the first time. The user-side promise we framed there is the one we're trying to deliver here.
• darkbloom.dev, whose framing of signed, portable artifacts of work informed how we think about receipts.

If you've read either of those, this won't surprise you. If you haven't, the rest of this post is the short version of what we're building and why the exchange is the only piece of state we own.

The shape of the thing

cocore has three kinds of participants:

• Requesters want compute done — an LLM inference, a render job, a training step. They sign in with their AT Protocol identity (Bluesky handle, normally) and publish dev.cocore.compute.job records on their own PDS.
• Providers have hardware that can do compute — a Mac mini under someone's desk, a homelab GPU rig, an idle server in a closet (today only Apple Silicon Macs run the agent, but the protocol isn't picky about what's on the other end). They run the cocore agent, attest their environment, and publish dev.cocore.compute.receipt records on their own PDS for every job they complete.
• The exchange is the piece in the middle. It maintains the token balance that lets requesters pay and providers earn, takes a 5% fee on every receipt for the treasury, and publishes its terms openly in a dev.cocore.compute.exchangePolicy record.

The first two are owned entirely by their respective users — provider receipts live on provider PDSes, job records live on requester PDSes, and the protocol-level export tool (com.atproto.sync.getRepo) is the migration path. Nothing in this repo holds authoritative state about who did what work for whom.

We own our exchange, but anyone can run another one against the same firehose with whatever market dynamics they want to encode — different fee schedules, different floors, different patronage cadences, different settlement rules entirely. In the future you can imagine several interoperable exchanges existing side by side, each indexing the same set of receipts and offering members a choice of how they want their work settled.

What the exchange actually does

The exchange keeps a per-DID token balance. Tokens are the unit of account: one token of model input or output costs one token from your balance. The exchange's role is the one a clearinghouse plays: net out who owes whom and hold the state.

How balances change

Four things move your balance, all in tokens:

1. Initial grant. Every DID that interacts with cocore for the first time gets 1,000,000 tokens on the house — enough to run a few thousand small completions and form an opinion of the network before contributing compute. Issued exactly once per DID; the policy record carries the amount as tokenGrant.
2. Earning compute. Every signed receipt your provider publishes credits your balance for 95% of the receipt's tokens. The other 5% routes to the cooperative's treasury.
3. Spending compute. Every job dispatched debits your balance for the receipt's tokens. The exchange does not take a separate cut from you — the treasury fee comes out of the provider's share (it's the same 5%, viewed from either side of the receipt).
4. Weekly refresh. Active members get a small weekly drip (≈70,000 tokens). "Active" means you've touched the network in the refresh window — earned a receipt, dispatched a job, read your balance. Dormant DIDs accrue nothing. This is the use-it-to-keep-it dignity floor; it stops a member who hasn't logged in for a month from getting locked out, without paying out to inactive ghost accounts.

On top of that, once a month the treasury distributes ~80% of its accumulated balance back to active members in proportion to their patronage during the period (tokens spent + tokens earned). This is the Rochdale-tradition co-op dividend — REI's annual rebate, a credit union's quarterly capital credit. The 5% per-receipt fee is the operating budget; the monthly rebate is the part that comes back.

The floor

There's a 100,000-token admission floor: if your balance is below that, your job will not run. Period. We set the floor high enough that no single message is likely to consume the whole thing, so the only cold-balance failure mode you ever hit is "wait for the next weekly refresh" — not "your job ran and the settlement bounced halfway through".

The admission check is published as the policy's tokenFloor field so clients (and other exchanges) can replicate it without asking us.

Why this shape

The mechanics above come from cooperative practice — Sardex/WIR mutual credit, REI's annual member dividend, electric cooperatives' patronage refunds. The property they share is honest legibility: a member can compute their share of the surplus and watch it arrive on schedule.

What we own, what we don't

We own an exchange. It runs a single instance at cocore.dev today, under one DID, with a published policy that anyone can read. The /docs/inference page enumerates the lexicons; the records themselves are publicly indexed on Bluesky's firehose like any other AT Protocol record.

We do not own the receipts. A dev.cocore.compute.receipt record lives on the provider's own PDS, signed at the repo layer. Anyone — including a future competing exchange — can index those receipts and offer a different settlement model. We can't quietly edit history or revoke receipts after the fact.

We also don't own identity. Your DID is yours; if you stop liking cocore, you can take your PDS data anywhere AT Protocol is spoken.

← Back to all posts