The Golem Project: crowdfunding white paper

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.