How murakumo.cloud's decentralization actually works today

For decentralized-compute-native readers (Render/Akash/io.net/Bittensor-adjacent) evaluating the "blockchain-native" claim before taking it at face value

We repositioned murakumo.cloud's homepage as a "blockchain-native decentralized GPU platform." That phrase does real work, but it's also exactly the kind of claim a decentralized-compute-native reader — someone who's used Render Network, Akash, io.net, or a Bittensor subnet — will want to verify before taking seriously. So: here's the actual mechanism, split into what's live, what's real-but-narrower- than-it-sounds, and what's roadmap. No chain, no token, no whitepaper. Just the parts we can point at.

"No central scheduler" — what that actually means

Placement (which node runs which replica) is computed by a deterministic best-fit function: sort demand largest-first, for each GPU class the demand accepts compute a bid score (price × count + a small fragmentation penalty for how tight the fit is), and take the lowest bid, breaking ties deterministically by node order. That function is pure — no network calls, no hidden state — and it's compiled into three places that all run the exact same code: the CLI, the production fleet control plane, and your browser.

That last one is the part worth checking yourself, not taking our word for: open the Playground, move a load slider, and watch placements recompute live, client-side, in front of you. You are not looking at a rendering of a server-computed decision — you're running the identical scheduler function locally that the production fleet runs.

Worth being precise about the word "auction" here: this is a deterministic cost-minimization heuristic, not a multi-party consensus protocol. There's no Byzantine fault tolerance, no independent nodes voting, no leader election. "Leaderless" means something narrower and more concrete: no single scheduler service holds placement logic you have to trust blindly, because the same pure function runs wherever you run it. That's a real property. It is not the same property a blockchain consensus mechanism gives you, and we're not implying it is.

"Content-addressed" — what that actually means

Each tenant's ledger graph ID is derived from identity, not assigned sequentially: SHA-256 the (did, db-name) pair, prefix the digest with the standard CIDv1 multiformat header for dag-cbor + sha2-256, base32-encode it. That's a real CIDv1, not a marketing use of the word "CID" — it follows the same multiformat spec IPFS uses, so if you know that spec you can verify the byte layout yourself. What it buys you: the graph identifier is a function of who you are and what you're writing to, not a database auto-increment — anyone with the inputs can independently derive the same ID, without asking us.

Decentralized identity — real, but narrower than "you get a wallet login"

GPU fleet nodes authenticate their writes to the append-only run ledger using a did:key-derived identity and a self-issued CACAO capability token (Ed25519, the SIWE/EIP-4361-style CACAO spec) instead of a shared static API secret. Concretely: a node derives its own did:key from a seed, signs a scoped, nonce'd capability for a specific graph and audience, and that signed token — not a bearer token issued by us — is what authorizes the ledger write.

Be clear about the scope of that claim: this is fleet-node-to-ledger authentication, not customer-facing wallet login. There's no "connect wallet" button on murakumo.cloud today. If we build one, this is the technical foundation it would sit on — but we're not claiming it exists yet just because the underlying primitive does.

What's genuinely not live — the roadmap, not the pitch

• On-chain settlement. Not implemented. The storefront has a "Pay with crypto — coming soon" button and it's disabled, on purpose, because it isn't built. Payment today is Stripe (card), full stop.
• A token. There is no murakumo token, no plan announced with a timeline. If that changes, it'll be a separate, specific announcement — not something this post is hinting at.
• A public marketplace where third parties list arbitrary GPUs. Today the mesh is our own rented cloud GPU capacity plus the kotoba-lang/murakumo self-hosted Apple Silicon fleet (that repo is public — the scheduler client, fleet config, and node agent are readable, unlike cloud-murakumo's server-side code, which isn't open source yet). It is not yet an open marketplace anyone can list a GPU into permissionlessly.

Why we're publishing this instead of just running ads

Our GTM plan for this positioning explicitly gates any push into decentralized-compute-native channels — hackathon sponsorships, Render/Akash/io.net/Bittensor community cross-posts — behind either shipping on-chain settlement for real, or publishing something exactly like this: a page a skeptical reader can check claim-by-claim. We picked the second, because it's true today and the first isn't. If you read this and the mechanism doesn't hold up, we'd genuinely like to hear where — that's the point of publishing the actual architecture instead of a positioning statement.