Introducing FoodBlock: The Data Primitive for Food

The global food system is one of the most complex networks on the planet. Every day, billions of interactions happen between farmers, processors, distributors, retailers, restaurants, and consumers. A tomato moves from a farm in Kent to a market stall in Borough, gets bought by a restaurant, transformed into a sauce, and served to a customer who leaves a review. Each of those interactions generates data -- but today, that data is scattered across dozens of incompatible systems.

We built FoodBlock because we believe the food system deserves a universal language. Not another platform. Not another database schema. A single data primitive that can represent every food interaction, from farm to fork, in a way that any system can understand.

Why we built FoodBlock

If you have ever tried to connect two food businesses digitally, you know the pain. One system tracks products with SKUs. Another uses UPCs. A third has its own internal IDs. Certifications live in PDFs. Supply chain data is locked in proprietary platforms. Reviews are siloed in apps that do not talk to each other.

The result is that no one has a complete picture. The farmer does not know where their produce ends up. The consumer does not know where their food comes from. The food bank cannot see the surplus that exists three streets away. And AI agents -- which could automate ordering, inventory, and logistics -- have no shared data layer to operate on.

We needed something simpler. Something so fundamental that it could represent a tomato, a recipe, a delivery, a review, a farm, and a restaurant -- all with the same structure. Something content-addressed, so the same data always produces the same identity. Something append-only, so history is never lost.

That something is FoodBlock.

The three fields: type, state, refs

A FoodBlock is a JSON object with exactly three fields. That is it. No more, no less. The identity of a FoodBlock is the SHA-256 hash of its content. Same content, same hash. Different content, different hash.

{
  "type": "substance.product",
  "state": {
    "name": "Organic Sourdough Loaf",
    "price": 4.50,
    "weight_g": 800,
    "organic": true,
    "allergens": ["gluten", "wheat"]
  },
  "refs": {
    "seller": "a3f8c2...64-char-hex-hash",
    "location": "b7d1e4...64-char-hex-hash"
  }
}

type tells you what the block represents. It uses dot notation for subtypes: substance is the base type for ingredients and products, substance.product is a specific product for sale.

state is a flat JSON object containing the block's properties. For a product, that might be a name, price, and allergen list. For a review, it is a score and text. For a farm, it is a name and acreage.

refs is a map of role names to other FoodBlock hashes. This is how blocks reference each other. A product refs its seller. A review refs its subject and author. An order refs the item, buyer, and seller. Refs create the graph.

Content-addressed hashing

Every FoodBlock's identity is derived from its content. We compute a SHA-256 hash of the canonical JSON serialisation of type + state + refs. This means:

• Same content = same hash. If two independent systems create a FoodBlock with identical type, state, and refs, they get the same hash. Deduplication is free.
• Tamper-proof. If anyone changes a single character in a FoodBlock, the hash changes. You can verify integrity by recomputing.
• No central registry. You do not need to ask a server for an ID. The content IS the ID. Anyone can create FoodBlocks offline.

This is the same principle behind Git commits and IPFS. It works at scale because hashes are cheap to compute, collision-resistant, and universally verifiable.

The six base types

Every FoodBlock has one of six base types. Three are entities (things that exist) and three are actions (things that happen). Together they can represent any food interaction:

• actor -- A person or organisation. A farmer, a restaurant chain, a food bank, an AI agent.
• place -- A physical location. The coordinates of a farm, a market stall, a commercial kitchen.
• substance -- An ingredient, product, or material. Tomatoes, sourdough, flour, a meal prep box.
• transform -- Changing one thing into another. Cooking, fermenting, milling. A recipe is a transform subtype.
• transfer -- Moving something between actors. A sale, a delivery, a donation, a surplus rescue.
• observe -- Making a statement about something. A review, a photo, a certification, a health inspection.

Subtypes use dot notation. actor.venue is a restaurant or shop. transfer.order is a purchase. observe.review is a customer review. Any system that understands the six base types can process any FoodBlock, even subtypes it has never seen before.

How blocks reference each other

The real power of FoodBlock is the graph. Blocks reference each other through refs, and you can follow those refs backwards to trace the complete provenance of anything. Here is a review that references the product it is about and the person who wrote it:

{
  "type": "observe.review",
  "state": {
    "score": 4.8,
    "text": "Best sourdough in Kent. Perfect crust.",
    "verified_purchase": true
  },
  "refs": {
    "subject": "c9a2f7...product-hash",
    "author": "d4e1b3...reviewer-hash"
  }
}

And here is an order that links a buyer, a seller, and a product:

{
  "type": "transfer.order",
  "state": {
    "quantity": 2,
    "amount": 9.00,
    "currency": "GBP",
    "status": "confirmed"
  },
  "refs": {
    "item": "c9a2f7...product-hash",
    "from": "a3f8c2...seller-hash",
    "to": "e5b7d1...buyer-hash"
  }
}

Updates work the same way. FoodBlocks are append-only -- you never edit one. Instead, you create a new block with refs.updates pointing to the previous version. This gives you a full version history for every entity in the system, and makes it trivial to audit changes.

Comparison to existing approaches

The food industry is not short on data standards. GS1 barcodes, GPC product categories, GDSN data synchronisation -- these have been around for decades. They work well for what they were designed for: identifying packaged goods in retail supply chains.

But they were not designed for the modern food economy. They cannot represent a home cook selling meal prep on Instagram. They cannot encode an AI agent placing an order on behalf of a restaurant. They cannot capture the provenance of a sourdough starter that has been fermenting for fourteen days. And they definitely cannot do all of this with a single, unified data model.

Paper trails -- certificates of origin, food safety audits, supplier contracts -- are even worse. They are unstructured, hard to verify, and impossible to query. When a food safety incident happens, tracing the source can take weeks.

FoodBlock does not replace these systems. It gives them a common language. A GS1 barcode can be stored in state.gtin. A food safety certificate becomes an observe.certification block with a ref to the inspected entity and the certifying authority. Everything connects through the graph.

What comes next

FoodBlock is the foundation. On top of it we are building the FoodX network: a marketplace where any food business can list, sell, and track products using FoodBlocks. AI agents that can autonomously manage inventory, place orders, and rescue surplus food. A trust layer computed from the graph itself -- not from platform ratings.

The protocol is open. Anyone can create FoodBlocks, no registration needed. We have published SDKs for JavaScript, Python, Go, and Swift. The whitepaper is available on our protocol page. And if you are building something in the food space, we want to talk to you.

The food system is a network. It has always been a network. FoodBlock just gives it the language it has been missing.