Can Kusama's infrastructure providers become the ecosystem's private inference layer?

Decent is about to provision a personal server for every member and collective it onboards, each running heavy creative-AI workloads (video, audio, image) against open-source models — and rather than send that inference and the money to a US hyperscaler, we want to buy it from Kusama's own infrastructure providers, paid in dUSD on Kreivo, at roughly a third of hyperscaler cost and with cryptographic proof the workload ran privately.

Imagine a town that is about to get a lot of new residents. Each resident wants to run a small workshop — not metal-and-timber, but creative: making short films, music, images, edits. The workshops are cheap to open, but they all need the same expensive thing: a communal kiln. No single workshop fires it often enough to justify owning one, yet when it is fired it transforms a whole batch of work at once — a short, intense, costly burst. That is exactly the shape of the compute creative AI runs on.

Today the obvious move is to rent kiln-time from a giant out-of-town utility — the big cloud companies. It works, but three things chafe. It's expensive. Your designs and your customers' orders pass through a company you don't control, so it's not really private. And every pound you spend leaves the town.

Now notice something: the town already has people who run critical machines for a living. In Kusama's case, these are the validators, collators, RPC operators and infrastructure teams who keep the network alive. Their normal validator role is CPU-, memory-, storage- and bandwidth-heavy — not GPU-heavy[^validator] — but they are already professional operators of always-on systems. What if some of those operators could opt into a separate GPU role, selling kiln-time — creative-AI compute — to the residents, and being paid in the town's own money?

That is the whole proposal. Decent is bringing the residents. Kreivo and dUSD are the town's money and membership. The open question — the one we'd genuinely like the community's help with — is whether Kusama's infrastructure providers can also become the town's shared kiln: a place to run creative-AI inference that is cheaper than the hyperscalers, keeps the money circulating inside the ecosystem, and can prove it ran your work without snooping on it.

The obvious follow-up questions — what exactly is "inference", how private is "private", does the maths actually work, and would a validator ever want this? — are what the rest of this document answers.

Everything named here is defined from scratch. If you already know a term, skip its box.

Decent

A media house and venture studio. Its model is to onboard members and collectives — creators, small studios, communities — and give each one a working environment to produce and own their creative output. Concretely, each onboarded party gets a provisioned personal server (a zo.computer instance: a cloud Linux machine with an AI agent attached). That instance is where their creative work happens.

The workload we're bringing

These are not chat sessions. Creative production means rendering — generating and editing video, audio, and images at volume, against open-source models (weights you can download and run yourself, e.g. Wan, HunyuanVideo, LTX-Video for video; open image and audio models beside them). Rendering is bursty and heavy: a single short video clip can occupy a top-end GPU for minutes; a production day is thousands of such bursts.

Inference (the thing we need to buy)

Running a trained model to produce an output — turning a prompt into a video, a stem into a master, a sketch into a frame. Distinct from training (making the model in the first place, which we are not proposing to do here). Inference for creative models is GPU-bound: it needs data-centre graphics cards (H100/A100 class), and its cost is essentially GPU-seconds × price-per-GPU-second.

Kreivo

The Kusama-based chain Decent already runs its membership and identity on. It's where a Decent member is a member — a first-class on-chain account with its own community/DAO. It's the natural place to also record who is entitled to compute and who gets paid for providing it.

dUSD

The dollar-denominated stablecoin circulating on the Kreivo/Kusama stack — issued by Brale (a US-regulated stablecoin issuer) in partnership with Decent Partners, alongside card rails. It's the settlement medium. When a member renders a video, the meter runs in dUSD; when a provider supplies the GPU, they're paid in dUSD. No token-price volatility sits between the work and the payment.

Kusama's infrastructure providers (the potential supply)

Validators, collators, RPC operators and ecosystem infrastructure teams already run serious, always-on services and are trusted, staked, reputation-bearing actors in the network. They do not run GPUs as part of ordinary Kusama validation; validation is a separate job with its own hardware profile.[^validator] The proposal is to ask whether that operator class could also support a new, opt-in GPU provider role — isolated from consensus duties — for those who already have GPU capacity, can provision it, or can coordinate with providers who do.

Confidential computing (what makes "private" real)

A hardware feature (e.g. Intel TDX, paired with H100/H200/B200 GPUs) that runs a workload inside an encrypted enclave the host operator cannot read into, and emits a cryptographic attestation proving which code ran in which environment. This is the primitive that turns "trust me, I didn't look at your footage" into "here is a proof I couldn't have." It already exists commercially on decentralised GPU networks today.[^ionet]

One-line synthesis: Decent supplies bursty creative-AI demand and an on-chain membership+money layer (Kreivo/dUSD); Kusama's operators are a candidate supply of GPU capacity; confidential computing is the bridge that lets the two meet privately; the missing piece is a way to match them.

To reason about this you need one lens: for a bursty GPU workload, the binding cost is not the price per GPU-hour — it's the price per GPU-hour ÷ your utilisation. A card you rent for an hour but only fire for twenty minutes costs you three times its sticker rate per unit of actual work. Every option below lives or dies on that ratio.

There are three places to run our inference. Each fails or wins on a different axis.

1. Hyperscalers (AWS, GCP, Azure). Reliable, elastic, and expensive: H100 on-demand sits around $4.50–$5.50/hr.[^h100] Two structural problems beyond price. First, privacy: your prompts, your source footage, your members' unreleased work all transit a US vendor's infrastructure under their terms. Second, leakage: every pound spent exits the ecosystem entirely. For a project whose entire thesis is keeping value inside a network, routing its single largest variable cost to Amazon is a contradiction.

2. Decent runs its own GPUs. Maximum control and privacy, but it puts a capital-intensive, spiky-utilisation hardware business on the critical path of a media house. GPUs are worst-owned by whoever has the least smooth demand — and early-stage bursty creative demand is the least smooth there is. This is precisely the utilisation trap above: we'd own cards that sit cold between bursts.

3. Kusama infrastructure providers (the proposal). Decentralised GPU markets already clear H100 at $1.20–$1.80/hr — a 60–70% discount to hyperscalers[^depin] — because they aggregate operators who already own the metal and want to smooth their own utilisation. Kusama has a neighbouring, but not identical, population: staked, reputationed, always-on infrastructure operators. The proposal is not that validators already have GPUs, or that validation should depend on GPU rental. It is to build an opt-in matching layer natively, so that:

• Demand comes from Decent members' instances (identified on Kreivo).
• Supply comes from Kusama operators offering GPU capacity as a declared, non-consensus role.
• Settlement is dUSD, metered per job.
• Privacy is enforced by confidential-compute attestation, verifiable on-chain.
• The money stays in the ecosystem — a creator's render bill becomes a Kusama operator's revenue, denominated in the network's own stablecoin.

Where the current approach fails: today a Decent member who renders video has exactly one realistic path — a hyperscaler or a closed API — which is expensive, non-private, and extractive of ecosystem value. There is no native way to spend a creative-AI budget inside Kusama. This proposal is about building that path.

All figures are illustrative-but-sourced; the constants are in the appendix so you can rebuild them.

Unit cost of a render

Open video models on an H100 give a workable anchor. Wan 2.1 at 720p renders a 5-second clip for ~$0.40–$0.48 of H100 time at standard rates.[^wan] Lighter models (LTX-Video) render a 5-second clip in under 30 seconds on a single consumer 4090,[^ltx] i.e. far cheaper again. So one delivered minute of finished video is on the order of $5–$6 of raw H100 inference at hyperscaler rates — and roughly a third of that at DePIN/Kusama-operator rates.

The number you could cheat on — and won't

The tempting figure to quote is cost-per-GPU-hour ($1.50 sounds great). The honest figure is cost-per-delivered-render-minute, which must include:

• Utilisation drag. Bursty demand means paid-for-but-idle GPU time. At 40% utilisation, a $1.50/hr card costs $3.75/hr per hour of actual work.
• Failed/rejected renders. Creative work throws away most of what it generates. A cost model that counts only kept outputs, not all outputs, is lying. Budget 2–4× raw gen cost for delivered creative output.
• Overhead — orchestration, storage, egress, the confidential-compute performance tax (single-digit %).

The claim in Layer 0 ("~a third of hyperscaler cost") is a claim about the honest, all-in, cost-per-delivered-minute ratio, not the headline sticker rate — because both hyperscaler and Kusama-operator costs carry the same utilisation and waste multipliers, so the ratio between them survives. If we ever quote the sticker rate as the saving, call us on it.

Rough demand shape (illustrative)

If Decent onboards, say, 100 creative instances in year one, and each renders on the order of 10 delivered minutes/day, that's ~1,000 delivered minutes/day ≈ $5–6k/day of inference at hyperscaler rates, or ~$1.8–2.2k/day sourced from Kusama operators — call it ~$650k–$800k/year of GPU revenue that could accrue to network infrastructure providers instead of Amazon, denominated in dUSD. These numbers are shape, not forecast; the point is the order of magnitude and who receives it.

Availability caveat (stated honestly)

DePIN GPU supply is real but thin and volatile — one major network averaged ~334 GPUs available with only ~84 in use in a recent quarter, and capacity has swung >50% quarter-on-quarter.[^depin] A native Kusama inference role would be building supply, not assuming it. This is a reason the matching layer and the incentive matter as much as the raw price.

"Validators secure the chain; GPU rental is a distraction from that job." Fair, and the two must not be coupled — securing Kusama can't depend on, or be weakened by, a side compute business. But the population overlaps (staked, always-on, reputationed operators), and the revenue could strengthen the economic case for running Kusama infrastructure at all. The design should keep the compute role opt-in and isolated from consensus duties.

"Is confidential compute actually private enough for unreleased creative work?" Hardware enclaves + attestation are a genuine step-change over "trust the operator," and are shipping commercially today.[^ionet] They are not magic — side-channels and supply-chain trust in the silicon vendor remain. Honest answer: materially more private than a hyperscaler, not unconditionally private. Worth stating plainly to members.

"Why not just use io.net / Akash and skip building anything?" We might, as supply — this isn't NIH. But those are external markets settled in their own tokens, outside Kusama's value loop and identity layer. The proposal's whole point is a role that is native to Kreivo/dUSD so demand, identity, payment, and privacy attestation live in one place the ecosystem controls.

"Bursty demand + thin supply = bad availability." Correct, and the biggest real risk (see Layer 4). Mitigations: a hybrid where hyperscaler/DePIN capacity is the overflow while a Kusama-native pool is grown; and an incentive that pays operators enough for readiness, not only utilisation.

Open questions to the community:

1. Who among Kusama's operators already has, or could add, H100/A100-class GPUs — and would you want a paid inference role?
2. What's the right shape for the matching layer — a pallet on Kreivo, an off-chain marketplace with on-chain settlement, an existing DePIN network wrapped in Kreivo identity?
3. How should confidential-compute attestation be verified and recorded — on-chain proof, or off-chain proof with an on-chain commitment?
4. What incentive design pays for readiness (idle-but-available) without simply subsidising idle hardware?
5. Is there appetite to treat "ecosystem inference" as a funded network priority (treasury / bounty), given the value-retention argument?

Constants used

• H100 hyperscaler on-demand: $4.50–$5.50/hr.[^h100]
• H100 DePIN/decentralised (io.net, Akash, Vast): $1.20–$1.80/hr, ~60–70% below hyperscaler.[^depin]
• Wan 2.1, 720p, 5-sec clip: ~$0.40–$0.48 of H100 time; ~10–12 min gen on H100.[^wan]
• LTX-Video, 5-sec clip: <30 s on a single RTX 4090.[^ltx]
• Confidential compute: Intel TDX + H100/H200/B200 with cryptographic attestation, commercially available on io.net.[^ionet]

Method for the demand figure. delivered-minutes/day = instances × minutes/instance/day; cost/day = delivered-minutes × cost-per-delivered-minute. Cost-per-delivered-minute derived from clip unit cost × (60/clip-seconds) × waste-multiplier × (1/utilisation). Swap in your own instance count, minutes, utilisation and waste multiplier to reproduce.

What this document does not claim. It does not claim DePIN supply is currently sufficient (Layer 4 says the opposite). It does not claim confidential compute is unconditionally private (Layer 5). It does not propose training on Kusama, only inference. The saving is claimed on an all-in cost-per-delivered-minute basis, never on sticker GPU-hour rate.

It also does not claim Kusama validators currently run GPUs. Normal validation does not require GPUs; any GPU supply would be a new, opt-in provider role adjacent to the existing infrastructure-operator role, not part of consensus.

Corrections and better numbers are actively wanted — this is a discussion draft, not a decision. If you run Kusama infrastructure and any of the above is wrong about your economics, that's the most useful reply we could get.

[^ionet]: io.net Confidential Compute VMs (Intel TDX + H100/H200/B200, cryptographic environment proof). https://io.net/blog/io-net-vs-akash-network-comparing-gpu-cloud-pricing-and-features [^validator]: Polkadot validator requirements list CPU, memory, NVMe storage and network requirements; GPUs are not part of the validator hardware profile. https://docs.polkadot.com/node-infrastructure/run-a-validator/requirements/ [^h100]: "H100 Rental Prices Compared" — hyperscaler H100 on-demand ~$4.50–$5.50/hr. https://intuitionlabs.ai/articles/h100-rental-prices-cloud-comparison and https://www.cloudzero.com/blog/h100-gpu-cost/ [^depin]: "DePIN GPUs for Inference: io.net, Akash vs AWS" — H100 $1.20–$1.80/hr, 60–70% discount; availability/utilisation caveat. https://www.buildmvpfast.com/blog/depin-gpu-inference-io-net-akash-below-aws-2026 [^wan]: Wan 2.1 720p 5-sec clip ~$0.40–$0.48 on H100; ~10–12 min gen. https://www.spheron.network/blog/ai-video-generation-gpu-guide/ [^ltx]: LTX-Video 5-sec clip <30 s on RTX 4090. https://ltx.io/blog/best-open-source-video-generation-models