Toolkit

Gridz is a monorepo of specs, packages, contracts, and examples. You don't need any of this to claim a profile — but if you're building an app, agent, or integration, here's what each piece is for.

TypeScript packages (`@gridz/*`)

Published from gridz-js. Install with pnpm add @gridz/core (etc.) once on npm, or develop from the superproject.

Package	You use it when…
`@gridz/core`	You need the Grid types, EIP-712 signing, canonicalization, merkle root, or offline `verifyGrid()`. Foundation for everything else.
`@gridz/sdk`	You want a typed HTTP client over a Gridz API plus core build/verify in one import.
`@gridz/cli`	You prefer the terminal: scaffold `gridz.yaml`, build/verify JSON, publish to a sink. See CLI.
`@gridz/sinks`	You need to store or read a Grid somewhere — ENS (primary for gridz.bio), SQLite, Postgres, S3, etc. Sinks are projections; signatures stay authoritative.
`@gridz/server`	You self-host a Gridz API (read + attestation-validated writes). Not required for gridz.bio users.
`@gridz/react`	You render a Grid in React with verification badges. gridz.bio uses a custom Spritz layout, but `@gridz/react` is the reference renderer.
`@gridz/vue` · `@gridz/svelte` · `@gridz/element`	Same renderer for Vue, Svelte, or a drop-in `<gridz-profile>` web component.
`@gridz/mcp`	You wire Gridz into an AI agent via Model Context Protocol — read/write Grids from Cursor, Claude Desktop, etc. Never signs server-side.
`@gridz/oneclaw`	Your agent identity uses a 1Claw HSM instead of a browser wallet. Optional; humans can ignore this.

Python packages

From gridz-py. Cross-runtime compatible with TypeScript — same signatures, same verification results.

Package	You use it when…
`gridz`	Core types, signing, and verification in Python (mirrors `@gridz/core` + SDK client).
`gridz_sinks`	Python sink adapters (ENS, SQLite, etc.).
`gridz_mcp`	MCP server for Python-based agents.
`gridz_oneclaw`	1Claw HSM signer adapter for Python agents.

Smart contracts

From gridz-contracts.

GridzResolver

The on-chain piece behind *.gridz.eth profiles. It is an ENSIP-10 wildcard resolver: when someone looks up you.gridz.eth, the resolver returns text records backed by EAS attestations on Ethereum mainnet.

What you care about — your published cells (alias, bio, url, widgets) are EAS attestations linked to your ENS namehash. Anyone with an RPC can read them; gridz.bio and the API are convenience layers.
What you don't need — deploying or upgrading the resolver. That is protocol infrastructure; claiming a profile uses it automatically.

Under the hood: each cell gets an EAS attestation with schema gridz.cell.v1; the resolver stores the attestation UID per (node, key) and serves decoded values via standard ENS text() reads.

Specs (source of truth)

The specs/ folder in the gridz repo defines the Grid JSON schema, attestation envelope, EIP-712 types, canonicalization rules, and OpenAPI 3.1 API. SDKs are generated and tested against these — not the other way around.

Examples

gridz.bio (examples/next-app) — this site: claim UI, profile pages, profile API, EAS publish.
minimal-cli — smallest end-to-end flow: gridz.yaml → sign → sink → verify → static HTML.
scaffold-agent-grid — agent-oriented Grid bootstrap.
oneclaw-quickstart — agent signing with 1Claw HSM.

How the pieces connect

You (wallet / CLI / agent signer)
        │
        ▼ sign cells + root  (@gridz/core)
        │
        ▼ publish            (@gridz/cli / gridz.bio / @gridz/sinks → ENS)
        │
        ▼ on-chain           (GridzResolver + EAS on Ethereum)
        │
        ├─► gridz.bio page   (read + render)
        ├─► Profile API      (read JSON)
        ├─► @gridz/react     (embed in your app)
        └─► verifyGrid()     (offline proof — no trust required)