LibraryStorage 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.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 3
Code
Source, repository, and what is actually hosted
- Golem white paperhttps://golem.network/doc/Golemwhitepaper.pdf
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
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.
Claim 02 · Paper model
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.
Claim 03 · Paper model
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.
Claim 04 · Paper model
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.
Claim 05 · Paper model
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.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 The commodity is a computation someone else runs
Observation
What the study says
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.
Model
What has to hold
The sandbox contains the payload well enough for the threat the user cares about.
Falsifier
What would retire it
How is this task verified, and what does verification cost relative to the work?
02 Tasks have to be divisible
Observation
What the study says
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.
Model
What has to hold
The task is divisible and has a verification method cheaper than redoing all the work.
Falsifier
What would retire it
Is the computation inside a sandbox the paper actually specified?
03 Verification is the hard half
Observation
What the study says
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.
Model
What has to hold
The task is divisible and has a verification method cheaper than redoing all the work.
Falsifier
What would retire it
Who is paid if two providers return different results and the check is inconclusive?
04 Sandboxes are there because providers are strangers
Observation
What the study says
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.
Model
What has to hold
The sandbox contains the payload well enough for the threat the user cares about.
Falsifier
What would retire it
What does the provider learn about the inputs?
05 A token clears the market in the paper's design
Observation
What the study says
Payment is denominated in the network's token. That is a choice about settlement, not a property of distributed rendering.
Model
What has to hold
Settlement completes even when the token's price moves between posting the task and paying for it.
Falsifier
What would retire it
What does the provider learn about the inputs?
03 Sequence
One action, as an operating tape
- 01A requestor packages a task, a verification method and a price, and posts it to the market.
- 02A provider with spare capacity takes a chunk and runs it in the required environment.
- 03The provider returns a result. The requestor, or the protocol's check, applies the verification the task declared.
- 04Payment is released for accepted chunks and refused or slashed for failures, under the market rules.
- 05The requestor assembles the chunks. The protocol does not know what the picture or the dataset means. It knows which checks passed.
04 Load-bearing
The argument, and where a pitch drops it
Not every computation has a cheap check
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
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.
Reputation will do the work the proof does not
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A 2016 crowdfunding paper is not a statement about the later network's usage.
Inputs may be the valuable part
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A 2016 crowdfunding paper is not a statement about the later network's usage.
05 Register
What has to be true
Model · Not re-measured
The task is divisible and has a verification method cheaper than redoing all the work.
Model · Not re-measured
Providers exist at the price offered. A marketplace diagram does not create spare GPUs.
Model · Not re-measured
The sandbox contains the payload well enough for the threat the user cares about.
Model · Not re-measured
Settlement completes even when the token's price moves between posting the task and paying for it.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
Concepts
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.