Library Storage and networks2016Design paperCorpus record

The Golem Project: crowdfunding white paper

Golem. Golem Factory.

Golem Factory's 2016 paper for a marketplace of spare computer power. Requestors split tasks. Providers run them. A reputation and payment layer is supposed to make the exchange work without a single render farm. The paper is explicit that it was also a crowdfunding document. This page uses the technical design and ignores the sale.

Golem's paper describes a marketplace for spare computer power: requestors split a task, providers run it in a sandbox, and a payment is released when the result checks out.

The five-minute read

The commodity is a computation someone else runs

A requestor does not buy a machine. They buy the execution of a task, verified well enough to pay for, on hardware they do not administer.

Tasks have to be divisible

The paper's early targets, such as rendering, can be split into frames or chunks. A task that cannot be split, or whose pieces depend on secret intermediate state, fits the market badly.

Verification is the hard half

A provider can return garbage. The paper relies on redundancy, spot checks, or task-specific checks. There is no universal proof that an arbitrary program was run honestly. Later proof systems are a different literature.

Sandboxes are there because providers are strangers

The computation has to be contained. The paper's threat model includes a requestor who sends a malicious payload and a provider who snoops on inputs.

A token clears the market in the paper's design

Payment is denominated in the network's token. That is a choice about settlement, not a property of distributed rendering.

One action, walked through

A requestor packages a task, a verification method and a price, and posts it to the market.
A provider with spare capacity takes a chunk and runs it in the required environment.
The provider returns a result. The requestor, or the protocol's check, applies the verification the task declared.
Payment is released for accepted chunks and refused or slashed for failures, under the market rules.
The requestor assembles the chunks. The protocol does not know what the picture or the dataset means. It knows which checks passed.

The argument, unpacked

Not every computation has a cheap check

Rendering can be spot-checked. An arbitrary binary often cannot. The paper is honest when it specialises. A claim that the network runs 'any computation' without a verification story is not this paper. It is a data centre with extra steps.

Reputation will do the work the proof does not

Where verification is partial, providers accumulate reputation. Reputation concentrates the market on a few operators, which is the opposite of the spare-cycles story. The paper lives on that tension.

Inputs may be the valuable part

Sending a scene to a stranger to render sends the scene. Confidentiality is a product requirement the white paper's sandbox only partly addresses. If the input cannot be shared, this market is the wrong shape unless a later private-execution layer is actually in use.

What has to be true

The task is divisible and has a verification method cheaper than redoing all the work.
Providers exist at the price offered. A marketplace diagram does not create spare GPUs.
The sandbox contains the payload well enough for the threat the user cares about.
Settlement completes even when the token's price moves between posting the task and paying for it.

What happened after the paper

Golem shipped a network aimed first at rendering and later at a broader compute API. Usage was the binding constraint, as it is for most spare-capacity markets. The paper's durable lesson is the verification problem: pay for a result you can check, and do not pretend an unchecked result is a proof.

What to check before you use the idea

How is this task verified, and what does verification cost relative to the work?
What does the provider learn about the inputs?
Is the computation inside a sandbox the paper actually specified?
Who is paid if two providers return different results and the check is inconclusive?

Terms

Requestor: The party who posts a task and pays for checked results.
Provider: The party who runs a chunk on their hardware.
Verification: The check that decides whether a result is paid. It has to be cheaper than simply redoing the task.
Sandbox: The containment around a stranger's code, meant to limit both snooping and damage.

The problem the paper names

Heavy jobs such as rendering sit in queues at specialist farms, while idle machines elsewhere cannot be hired in a standard way. Golem proposes a task definition, a provider application, and a verification story so a requestor need not trust one farm.

What the design proposes

A requestor posts a task and a budget.
Providers reserve resources and return results.
Verification and reputation are required because a provider can return garbage.

How the mechanism is specified

The paper's application registry is where computation models are published. Not every job fits one model.
Payment is escrowed around the task. The commercial terms of the 2016 sale are not the escrow design, and are not repeated here.
Verification that works for rendering may not work for a general program. The paper is most concrete on the jobs it names.

What this page does not treat as proven

A 2016 crowdfunding paper is not a statement about the later network's usage.
Verifying arbitrary computation by re-execution is circular if the re-executor is as untrusted as the provider. The paper does not fully close that loop for every job type.
We do not describe a token sale.

Why a venture studio still reads it

The ancestor document for 'a market in spare compute'. Pair it with livepeer for a narrower media job, and with TrueBit-style verification thinking when the venture claims any program can be checked. Golem is honest that the task model matters.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.