To the crypto community: we did not start GRID because the world needs another ticker, another dashboard, or another claim that a protocol is finished before it has earned that description. We started it because there is a harder question worth answering. Can a network recognize useful computational contribution, verify it with evidence, and let ordinary machines participate in something larger than themselves?
Blockchains taught the world that strangers can coordinate around shared rules. They also made the cost of security visible. The next challenge is not to dismiss that lesson. It is to carry it forward: to build systems where security work and useful work can reinforce one another, while remaining honest about who has authority and what remains centralized in the early stages.
GRID begins with a simple conviction: a network should be able to measure what a machine actually contributes, not merely what it can burn.
Two kinds of work, one accountable network
In Phase 1, GRID separates two jobs that are often blended together in crypto conversations. Transactions and settlement history need miners and peers that replicate, inspect, and verify signed data. Compute needs a way to describe available resources, assign authorized work, check results, and record the outcome. The first is the integrity path. The second is the utility path.
When we say TX = miners, we mean that GRID miners participate in the P2P verification path: they synchronize signed blocks, validate the settlement history they receive, and perform capped proof-of-resource verification work. This is not a promise that every machine is already a permissionless block producer. Today, Genesis signs canonical Phase 1 blocks. Connected peers can inspect and reject invalid signed history, but Genesis remains the finalizer while independent validator quorum is built and audited.
When we say Compute = PoR, we mean that useful capacity needs its own evidence trail. A machine’s CPU, GPU, memory, storage, bandwidth, availability, and completed jobs are not automatically valuable simply because they exist. Contribution has to be authorized, measured, verified, scored, and settled. That process is what we call Proof of Resource.
01 · TX
Miners verify
P2P miners replicate signed history and perform capped verification work.
02 · COMPUTE
PoR measures
Authorized work is measured, checked, scored, and turned into a receipt.
03 · SETTLEMENT
Peers inspect
Genesis signs Phase 1 blocks; connected peers synchronize and verify them.
Today, Genesis remains the finalizer. This diagram shows the running pilot, not a claim of decentralized finality.
What Proof of Resource actually means
Proof of Resource is not a slogan for “any computer gets paid.” It is a discipline for recognizing useful participation. In the model described in the GRID white paper, a contributor offers constrained resources; the network coordinates an authorized task; the result is checked; and a signed receipt becomes the basis for recognition. The important word is not resource. It is proof.
A good resource network has to be selective. It should care about whether the work was completed correctly, whether it arrived in time, whether the node is reliable, and whether the measurement can be repeated. Phase 1 therefore treats raw hardware as an input, not an entitlement. The coordinator verifies pilot work and produces settlement information; peers synchronize signed block history; the explorer gives the public a place to inspect the visible system rather than accept a marketing claim.
This is also why GRID is being built in layers. The first layer is observability: can operators see a peer, a receipt, a block, and a coarse network footprint without publishing sensitive node details? The second is verification: can the network reject a bad result rather than merely record an assertion? The third is execution: can workloads run inside a restrained, isolated host environment without getting access to operator vaults, private keys, host paths, or the container runtime itself? Each layer has to stand before the next one can carry real weight.
Why build it now
Compute is becoming a fundamental resource. It powers research, media, simulation, automation, local services, and the tools people use every day. Yet much of the world’s capacity is either locked inside large providers or left idle behind household, studio, and small-business machines. There is room for a network that gives those operators a meaningful way to contribute without asking them to surrender their identity, their keys, or control of their machines.
GRID is an attempt to make that contribution legible. A node should be able to say: these are the resources I am willing to offer; these are my limits; this is the work I completed; this is the proof; and this is the settlement record others can inspect. The operator remains an operator, not an invisible commodity. The network’s job is to coordinate around those boundaries, not erase them.
The goal is not to make every device public. The goal is to let every willing operator contribute with evidence, limits, and control.
The honest Phase 1 promise
Phase 1 is deliberately a beginning. The public system includes a Genesis node, an encrypted P2P path, proof-of-resource coordination, signed settlement-chain data, privacy-preserving registry pings, and an explorer. It also includes an Engine foundation for container hosting: runtime checks, encrypted-volume key scaffolding, and a tightly limited Git-backed Caddy service manifest. The Engine does not yet deploy customer containers or expose a production workload tunnel, and it should not be described as though it does.
Decentralized mainnet is not a label we can grant ourselves. It requires independent validators, enforced quorum certificates, durable segmented block storage, tested recovery, operational independence, clear treasury and allocation controls, and outside security review. Until that work is complete, Genesis leadership is a transparent Phase 1 fact—not something hidden behind language.
If you want to help, the most useful thing is not blind belief. Run a peer. Run a miner. Inspect the explorer. Read the white paper. Point out where the system’s claims exceed its evidence. Build with us only where the boundaries are clear. Trust in a network should grow from what people can verify, not what they are asked to imagine.
Continue reading
Start with the evidence.
Learn the contribution model, inspect the running pilot, or join as an operator. GRID is a work in progress; the public record should make that visible.