The master grid.

There is one master grid. It is a .grid file. It catalogs every other .grid file that chooses to join it.

Same format as every other Grid file. Same cells. Same addresses. Same chain. No daemon, no service, no special protocol holding it together. "No daemon" means the registry is just a grid, not that you run anything: the catalog of every registered grid in the world is one file, written by the same primitives as the things it catalogs.

The design is real and the format is locked. The one canonical instance launches when Grid goes open source; until then it is not on the public internet. When it ships, it will live on a dedicated computer and be managed by a Base 2 native resident. See the Bases. This page is the doctrine for what it is and how it works.

A single .grid file. Address layout:

@/system/genesis            master grid's own genesis cell
@/system/master-policy      rules for the master grid itself
@/system/capabilities/*     who can register, who can retract
@/grids/<x>/<y>/<z>         one cell per registered grid
@/grids/<x>/<y>/<z>/meta    optional public metadata for that grid

Every cell on the master grid is a normal Grid cell, and every read against it is a normal Grid expression. There is no "master grid API"; you query it the way you query any grid, over the network (see Searching the network, below).

The master grid governs itself by its own primitives. Its policy cells determine who can register, who can retract, what metadata is public. The policy is data. Changes to the policy are writes. The history of how the master grid was governed is queryable like the history of anything else.

Every Grid file has a coordinate [x, y, z] derived from its genesis cell via GHA-1024 (Grid Hash Algorithm). The coordinate is not assigned. It is not claimed. It is not registered for. It is a mathematical consequence of what the grid contains.

Coordinates are big numbers. The address space per axis is 2^48, roughly 281 trillion values per axis. Three axes. Most coordinates are 14 or 15 digits per number. A real coordinate looks like this:

[182473615824907, 94862175839204, 226815439728601]

Not three small digits. Three integers in a space large enough that collision is mathematically negligible for any human-scale corpus.

The master grid does not hand out positions. It records that a grid with a particular content-derived coordinate exists. Two parties who construct genesis cells from the same recipe end up at the same coordinate without coordinating. Two parties with different genesis cells get different coordinates even if the rest of their grids are identical.

The address of a grid on the master grid is exactly its coordinate:

@/grids/182473615824907/94862175839204/226815439728601

The coordinate is public and computable by design: anyone can derive it from your grid's content, and that is the point. The coordinate is not a secret. What proves a registration at that address is genuinely yours is your signed identity, not secrecy of the coordinate. The master grid records an entry only when it is signed by the identity that owns the grid.

The master grid itself has a coordinate too, derived from its own genesis cell the same way every other grid's is. There is no special "origin" position; the master grid is at wherever its genesis bytes hash to.

GHA-1024 is Grid Hash Algorithm: a 1024-bit hash construction designed for spatial, sensitivity-layered, hierarchical data. It is built on SHA-512 as its primitive, composed in Grid-aware ways. Its security rests on SHA-512; GHA-1024 is a construction on top of a standard, well-studied primitive, not a new cryptographic primitive of its own.

Structured output. 1024 bits, split deliberately:

GHA(address, body, sensitivity)
  = [content half: 512 bits] || [coordinate half: 512 bits]

The two halves are entangled. You can't produce a valid GHA by splicing halves from different cells. But each half is independently meaningful. The coordinate half can be reduced to a 3D position without exposing the content half.

Address-aware iteration. The hash decomposes the address into path segments and folds each segment into the hash state at its depth:

sigma_0 = SHA-512(body)
for i in 0..depth:
    sigma_{i+1} = SHA-512(sigma_i || depth_tagged_hash(segment_i))

Changing any segment of the address changes every subsequent state. Moving a cell from @/tasks/review to @/secrets/review produces a completely different hash even if the body is byte-identical. The address is structurally folded in. Not appended, not salted, folded.

Sensitivity hardening. More compute at higher sensitivity:

Brute-forcing sealed content costs 64x the compute of brute-forcing public content. The level tag is mixed in, so you can't precompute public hashes to attack sealed cells. The cost is asymmetric by design.

Master coordinate derivation. Take the coordinate half of GHA. Split it into three 21-byte slices. Reduce each modulo 2^48:

coordinate_half = GHA(genesis)[512:1024]
x = int(coordinate_half[0:21])   mod 2^48
y = int(coordinate_half[21:42])  mod 2^48
z = int(coordinate_half[42:63])  mod 2^48

The result is three integers, each in [0, 281474976710656). That's the grid's permanent address on the master grid.

Chain mode. Every cell's chain hash incorporates not just the previous cell's hash but a topology hash, the region hash of all preceding cells. Inserting, deleting, or reordering cells changes the topology fingerprint, which breaks every subsequent chain link. A linear chain hash can't detect topology tampering; GHA's chain mode can.

The master grid does what blockchains try to do, provide a public, tamper-evident record, without the consensus machinery blockchains pay for. It does not need global consensus, because there is one canonical instance, not a distributed set of mutually distrusting nodes.

A blockchain assumes a hostile, distributed environment where many parties can attempt to rewrite history, and solves that with proof-of-work or proof-of-stake. The master grid assumes a different model: a single canonical instance where integrity comes from two things working together.

• Tamper-evidence. Tampering with any cell breaks the chain hash for every cell after it. Inserting, deleting, or reordering cells changes the topology fingerprint, which breaks every subsequent chain link. A reader replays the chain from genesis and verifies, independently, with no quorum and no vote.
• Signed identity. Authorship is proven by signature. Every entry is bound to the identity that signed it, so "who registered this" is verifiable, not assumed.

The result is a public registry with no consensus overhead: one canonical instance, one chain, detection-based integrity, and signed authorship. This is not a claim to be more secure than a blockchain. It is a different mechanism for a different problem: a catalog with one source of truth, rather than a distributed disagreement to be resolved.

Registration is voluntary. A .grid file is fully functional without ever appearing on the master grid. The master grid is for grids that choose to be discoverable, and anyone with a grid can register their own.

Here is how you join, once the canonical instance is live. Your grid-core computes your grid's coordinate from its genesis via GHA-1024, then sends a signed registration to the canonical master grid over HTTP. The master records an entry bound to your identity:

1. Your kernel derives your coordinate from genesis and signs the request with your identity.
2. The master checks for an existing entry at that coordinate. If active, it is already registered; if retracted, the coordinate is tombstoned permanently.
3. The master writes a grid-entry cell at @/grids/<x>/<y>/<z> with the coordinate, your signed identity, the timestamp, and the chain hash.
4. You can include a grid-meta cell at @/grids/<x>/<y>/<z>/meta with name, description, and visibility (public, discoverable, or private).

Because the request is signed, only you can register your grid at its coordinate. The coordinate is public; the signature is what makes the registration yours.

Retraction is a signed write to the canonical master grid. It records a superseding grid-entry cell with status: retracted and a timestamp. The original entry stays in the chain (the chain is append-only), but live queries see the retraction.

Coordinates are never reused. A retracted coordinate stays retracted. The grid that produced it cannot re-register. To come back, write a new genesis cell: different bytes, different coordinate, different identity.

Only the registrant's signed key, or the founding identity, can retract. Any other request is silently no-op'd. Denial is invisibility; the master grid follows the same doctrine as every other grid. Signed identity is what authorizes the retraction.

The master grid is the catalog. You search the catalog over HTTP, then open any grid by its coordinate, the way you resolve an address on a network. Reads return only what each grid makes public.

Search the catalog (read the registry over HTTP):

study: [master]::@/grids/** where: type=grid-entry
study: [master]::@/grids/** where: slot: visibility = public
study: [master]::@/grids/** where: slot: name contains "calendar"
study: [master]::@/grids/** where: written-by = <identity>

Open a grid by its coordinate (the coordinate is the address):

fetch [182473615824907, 94862175839204, 226815439728601]::@/system/genesis
study: [182473615824907, 94862175839204, 226815439728601]::@/**
study: [182473615824907, 94862175839204, 226815439728601]::@/data/** where: slot: status = open

Resolve a cross-grid reference inside your own work (a cell that points at another grid resolves live):

fetch [x,y,z]::@/tasks/review

A few things to keep in mind:

• [master] is a placeholder. The canonical master grid's coordinate, or its GTP endpoint, is published at launch, once its genesis is written on the hardware. The long numeric coordinate in the open-by-coordinate examples is an illustrative example grid, not the master.
• These are reads over GTP (HTTP GET). Searching the network is reading; registration is the separate signed write.
• Remote reads return public cells only. When you open another grid by coordinate, that grid's own capability projection decides what an outsider can see, so private and sealed cells stay invisible. That is the trust model, and it is a feature.
• Signed identity is what makes written-by trustworthy. Filtering or auditing by written-by = <identity> only means something because the registration and the cells are signed.
• grid find ... and grid open [x,y,z] are ergonomic shortcuts that resolve to these expressions; they arrive with the canonical launch. The study: and fetch forms are the real mechanism. None of this is runnable today; it is how the network works when the instance is live.

Two addressing systems compose:

Local:    @/tasks/review
Global:   [182473615824907, 94862175839204, 226815439728601]::@/tasks/review

The :: separator is the bridge. Any grid expression can take a global address as a target:

study: [182473615824907, 94862175839204, 226815439728601]::@/data/**
fetch [182473615824907, 94862175839204, 226815439728601]::@/system/genesis

How it resolves:

1. For a grid you do not own, the kernel resolves the coordinate through the canonical master grid over HTTP to locate it, and reads the cells that grid makes public.
2. For your own grids, the kernel consults your private local index (next section) to find the file on your machine.
3. It opens the target as a read-only Grid and resolves the local part of the address inside it.

The composition lets any grid address any cell on any registered grid. From inside my.grid, you can pull a public cell from another grid by coordinate. The reference is durable: the coordinate does not change when a file moves or gets renamed. And because every cell carries a signature, a resident can verify who authored the cells it resolves across grids, so cross-grid memory is trustable, not just reachable.

This is the security separation that keeps the master grid public, and it is entirely yours. ~/.grid/index.grid is a private grid file on your machine. It maps coordinates to filesystem paths for your own grids. It is never shared, never networked. It is the answer to "where on my disk is the file at this coordinate?", and only your machine knows. It is not part of the master grid.

The master grid carries coordinates. Your local index carries paths. The two never combine on a shared surface.

Why this matters:

• The master grid can be public. Coordinates leak nothing about where files live.
• Sharing or reading the master grid never exposes filesystem layouts. No /Users/<your-username>/... paths leak.
• Different machines keep different local indexes for the same coordinates. Each machine knows where its own copies live.

When you register, your coordinate goes to the canonical master grid and the path goes only into your local index. Cross-grid resolution uses your local index to turn a coordinate for one of your own grids into a file handle.

Grid is purely native otherwise. Every .grid file is a local file. The CLI is one binary, the console is one binary. There is no server, no daemon, no required network connection. Local work is hermetic, and the default state of any Grid project is offline.

The master grid is the one exception. When the canonical instance is online, it is reachable over GTP (Grid Transport Protocol) over HTTP, and it carries two kinds of traffic:

• Reads (HTTP GET): coordinate lookups, discovery, and opening the public cells of registered grids. This is what Searching the network, above, does.
• Writes: a registration or a retraction is a signed call to the canonical master grid, authorized by your identity.

GTP exists only for the master grid. Local grid-to-grid operations on your own machine never touch the network. Both the read and write paths are pending the canonical deployment; until the instance is live, neither is reachable.

The coordinate space is enormous. Each axis holds 2^48 values:

281,474,976,710,656 values per axis

Three axes. Total coordinate space: ~2^144, roughly 2.2 x 10^43 possible coordinates. Effectively infinite for any human-scale corpus.

Practical capacity is bounded by hardware, not address space. The master grid is a .grid file like any other; it scales the way every .grid file scales:

• Each registered grid is one cell at @/grids/<x>/<y>/<z>, plus an optional metadata cell. Roughly a few hundred bytes per registered grid in the append-only log, plus an index entry at the file tail.
• The sorted index gives O(log n) lookup. For 100 million registered coordinates, a lookup is ~27 binary-search steps. Microseconds on commodity hardware.
• For one billion: ~30 steps. Microseconds.
• The file lives memory-mapped on the dedicated machine. Reads are RAM-fast. Writes append to the end of the log and update the index.

With realistic compute on a dedicated machine (terabytes of storage, generous RAM), the master grid can comfortably manage hundreds of millions of grid coordinates, and scales to billions before the physical hardware becomes the constraint rather than the format. The address space itself will not run out for as long as physics permits.

The web was built for humans to find and read. Grid is built for AI to resolve and know. That difference is the whole point of the master grid.

How the web works, and who it is for. The web is documents at URLs, found by keyword search, ranked by popularity. A human types a fuzzy query, gets a list of pages, clicks, reads with their eyes, and reconstructs the meaning. Every layer, HTML, layout, SEO, ranking, is built for a human to read. When an AI uses that web it works against the grain: it scrapes HTML, strips boilerplate, parses prose, guesses what is current, dedupes, and re-derives meaning from a thing built for eyes. RAG is the tell: we bolt vector search onto human documents and hope the right chunk comes back. It is approximate, lossy, and provenance-free. The agent cannot tell who wrote it, when, or whether it changed.

How Grid is built for AI.

1. The unit is a cell, not a page. The web's atom is a document for a human to read; Grid's atom is an addressable claim.
2. Resolution, not search. The web makes an agent search, fetch, read, and extract. Grid lets it resolve: a coordinate plus an address returns the exact cell. The structure is the meaning, so there is nothing to parse and nothing to guess. RAG exists to fake addressable structure on top of prose; Grid is addressable by construction.
3. Provenance is native. Every cell carries who wrote it and when; supersession makes "what is true now" a property, not a guess; the chain makes tampering evident; signed identity makes authorship verifiable.
4. Read and write are the same surface. An agent cannot write back to a webpage; its memory lives somewhere else. In Grid, retrieval and memory are one substrate, so knowing and remembering stop being separate systems.
5. Coordinates, not registrars. A URL is assigned by DNS authority. A coordinate is derived from content, with no authority. The address is the thing.

The line that captures it: the web is search and retrieval built for humans to read; Grid is addressing and resolution built for AI to know and act. Where the web makes an agent scrape and guess, Grid lets it resolve the exact claim it needs, with provenance, in one call.

The payoff: persistent memory, ahead of its time. Most AI agents bolt on a vector store, a database, and a sync layer just to remember anything between sessions. With Grid, a resident's memory is already a grid, and the master grid gives that memory a coordinate. Persistent, addressable memory becomes one call: resolve a coordinate over HTTP and the agent is reading durable memory that carries its own provenance, signed, with nothing to provision and no infrastructure to stand up. Memory stops being a service you wire together and becomes a place the agent can reach.

Concretely, a resident with master-grid access can:

• Discover by intent. Find grids by name, type, visibility, or any public metadata slot the registrant exposed.
• Resolve cross-grid references live. Cite a cell in another grid by coordinate; the kernel pulls it on read. No copy, no sync. The other grid is its own source of truth.
• Bootstrap from templates. Find a public template grid by coordinate, derive the shape, write its own genesis.
• Compose across grids in one expression. Pull from a public coordinate, transform, write to a shared output grid, all addressable.
• Audit by identity. written-by = <resident-id> returns every grid a resident registered. Audit and cross-grid trust rest on signed identity.
• Hold long-running memory across many grids. Working memory in one grid, reference data in many, the master grid the index that makes them one navigable space.

One honest note: this is not "Grid replaces Google." The master grid is a catalog: you find grids by name, meta, or coordinate, then resolve by coordinate. It is exact addressing and provenance-rich knowledge for grids you know or find, not a crawler indexing the open web's prose. Everything above is what the master grid makes ordinary the moment it launches with Grid.

The master grid launches when Grid goes open source. The format and the protocol are locked. The canonical instance comes online together with the open grid-core everyone runs, and registering, resolving, and searching the network go live at the same moment.

This page is the doctrine for how that network works. To be there when it opens, join the waitlist below.