# kura 蔵

> Erasure-coded object storage on independently operated nodes. Priced in USD,
> settled in USDC on Base, no network token. Currently in Phase 0 — the coding,
> placement, audit and settlement planes run against rented backends as
> pseudo-nodes to measure the node-loss rate. NOT yet accepting customer data.

## What is actually measured

- Minimum distance of the k=16/r=4/g=6 code: **8**, established by exhaustive
  search over all 657,800 seven-shard erasure patterns (zero failures) and all
  1,562,275 eight-shard patterns (1,464 failures). It meets the Gopalan bound
  rather than approaching it.
- Single-shard repair: **4 reads, zero field multiplies.**
- Audit cost: **0.005% of a node's capacity per year**, versus 1200% for a
  monthly full scrub. 688 challenges catch 1% deletion at p=0.999.
- Random sampling reported this code as tolerating one MORE loss than it does;
  the exhaustive search found the 1,464 fatal patterns the sample never drew.
  Sampling cannot measure worst-case erasure tolerance.

## What is modelled, not measured

- Every price and rate. Each carries `:provenance :modelled` or `:chosen` in
  `kura-bugyo/pricing`, and none is `:observed`. Phase 0 replaces them.
- The durability figure in nines. The code's distance is measured; the
  node-loss rate that turns it into nines is not, and will not be until Phase 0
  has run. Anyone quoting nines for a network that has not measured its own
  node population is quoting a model.

## Against Storj — read 2026-07-29, point-in-time

|  | retail / TB-month | expansion | cost of goods | margin |
|---|---|---|---|---|
| Storj | $7.00 | 2.76x | $4.14 | 41% |
| kura launch | $4.62 (34% less) | 2.00x | $3.00 | 35% |
| kura target | $3.75 (46% less) | 1.625x | $2.44 | 35% |

We pay node operators exactly what Storj publishes: $1.50/TB-month storage and
$2.00/TB egress (they pay the same $2.00 for audit/repair bandwidth). So the
cheaper price is **not** an undercut of the people running hardware, and **not**
a fatter margin — ours is thinner. The entire difference is the storage
multiplier.

Live and computed rather than typed:
https://kura-coordinator.04-feasts-minded.workers.dev/pricing

### Why there is still no token

Storj's own July 2025 tokenomics update diagnosed their payment token as a
pass-through: bought on the market to pay operators, sold by operators to pay
power bills, net-neutral on price. Their fix diverts 5% of monthly payouts into
buybacks to manufacture holding demand. That 5% is a cost a network settling in
USDC does not carry. The incumbent's own restructuring is the strongest
available argument against issuing one.

## Pricing (modelled)

| configuration | multiplier | storage | egress |
|---|---|---|---|
| launch (today) | 2.00x | $4.62 / logical TB-month | $3.08 / TB |
| target (after Phase 0) | 1.625x | $3.75 / logical TB-month | $3.08 / TB |

Launch is conservative on purpose: launching optimistic and finding the
node-loss rate is worse loses data irreversibly; launching conservative and
finding it is better is a price cut. Egress is NOT multiplied by the code — a
systematic read reconstructs nothing.

## Node operators

Permissionless. Bond is USDC, $7.50 per committed TB, priced against the
repair bill rather than against what a cheat would gain. The bond is
collateral and is returned; its real cost is ~4.1% of revenue at a 10%
opportunity cost.

## Running a node — the door is open, the bond is not

- https://kura-coordinator.04-feasts-minded.workers.dev/operator/quote?tb=50 —
  what you would bond, earn and be audited on. Runs the same function the tests
  and the site do, so it cannot drift from them.
- POST /operator/register — records intent. **Takes no bond** (the escrow
  contract is not deployed) and **places no data** (Phase 0 accepts none). No
  authentication, because nothing is at stake yet; when a bond is attached the
  registration must be signed by the key that posts it, and that is a different
  endpoint.
- /operator/registry — who has registered, publicly.
- You can run a node on hardware you already own: the filesystem backend is
  part of the node software, verified 19/19 against a real directory. A machine
  somebody owns is the only failure domain addable without opening an account
  with anybody — and the fleet is currently one short (2 domains, launch layout
  needs 3, target needs 4). A permissionless network
  whose participant list is private is not one anybody can check the
  failure-domain spread of.

## What this is NOT

- Not a proof-of-storage chain. Audits are sampling plus collateral —
  detection with an economic consequence, not Filecoin's continuous on-chain
  proof. If you need public chain-verifiable proof, Filecoin is the right
  choice.
- Not trustless placement. A coordinator decides placement and payouts. It
  cannot lie about a payout total or a node's share without contradicting a
  published root, but it is a trusted point. Quorum coordination is planned,
  not shipped.
- Not independent by default. Shards on one provider's account are one failure
  domain whatever the code says. Every backend must declare its independence.

## Live, checkable now

- https://kura-conformance.04-feasts-minded.workers.dev/conformance — the
  shard-store contract against real Cloudflare R2 and Backblaze B2 buckets.
  Returns 500 if anything fails.
- https://kura-conformance.04-feasts-minded.workers.dev/status — the probe
  series: per-backend availability, median read latency, and an explicit
  refusal to quote a node-loss rate until the window reaches 168 hours.
- https://kura-conformance.04-feasts-minded.workers.dev/durability — stores an
  object across both providers, destroys shards on purpose, repairs, and
  compares recovered bytes. One shard lost costs 4 reads. Seven lost (the
  measured limit) still recovers. Eight is REFUSED rather than attempted and
  silently wrong; the route returns 500 if any scenario deviates.
- https://kura-conformance.04-feasts-minded.workers.dev/audit — how many
  genuinely independent failure domains the fleet has. It currently answers
  NO: two providers spread 32 shards 16-and-16, and the code tolerates 13.
  At least three domains are needed for the launch layout, four for the
  target. The audit answering no is the reason to trust the rest.

## Source

- https://github.com/kotoba-lang/erasure — GF(2^8) locally recoverable codes
- https://github.com/kotoba-lang/kura — placement, repair, audit, orders
- https://github.com/kotoba-lang/kura-node — shard backends, fast GF, audit responder
- https://github.com/kotoba-lang/kura-bugyo — pricing, collateral, epoch payout roots
- https://github.com/kotoba-lang/kotobase-storage-kura — kotobase.storage adapter

## Not offered yet

There is no paid API endpoint and no x402 catalog entry. Registering one
before the network accepts data would be the kind of overclaiming the rest of
this document exists to avoid.