Skip to content

JSON Database

Everything is JSON

The entire WeaveDB is represented as a self-contained JSON. The db instance has dirs, and each dir has docs. Metadata, configurations, and indexes are all stored in thier own dir, which makes every database operation verifiable.

const db = [
  { // dir[0] = "_"
    _: { index: 0, schema: {...}, auth: {...} },
    _config: { index: 1, schema: {...}, auth: {...} },
    __indexes__: { index: 2, schema: {...}, auth: {...} },
    __accounts__: { index: 3, schema: {...}, auth: {...} },
    users: { index: 4, schema: {...}, auth: {...} },
  },
  { // dir[1] = "_config"
    info: { id: "database_id", owner: "addressA", last_dir_id: 4 },
    config: { max_doc_id: 168, max_dir_id: 8 }
  },
  { // dir[2] = "__indexes__"
  },
  { // dir[3] = "__accounts__"
    addressA: { nonce: 4 },
    addressB: { nonce: 1 }
  },
  { // dir[4] = "users" | custom dir
    bob: { name: "Bob", age: 20, favs: [ "apple", "orange" ] },
    alice: { name: "Alice", age: 30, favs: [ "orange", "lemon" ] }
  }
]

In practice, this full JSON tree is not loaded entirely into memory. Instead, it is handled efficiently by WeaveKV, a pluggable key-value store adaptor that enables atomic data access between in-memory operations and persistent storage (e.g., LMDB, RocksDB). This approach ensures performance, modularity, and verifiability at every level.

Database scalability in WeaveDB is not limited by the protocol itself. Instead, it is determined entirely by the underlying key-value store and the hardware or cloud infrastructure it runs on. This design allows WeaveDB to scale indefinitely—both vertically (by upgrading hardware) and horizontally (by distributing KV partitions)—when deployed on top of scalable, cloud-native storage engines.

FPJSON (Code as Data)

Unlike traditional Web2 databases, WeaveDB is permissionless—anyone can submit state-changing queries anonymously. This requires more than just signature verification; it demands a robust access control layer that determines who can update which data, and under what conditions.

To solve this, we created FPJSON—a lauguage agnostic functional programming DSL encoded entirely in JSON. With over 250 composable functions, FPJSON allows you to express any computation or access rule as structured data.

This aligns with WeaveDB’s philosophy of code as data, making authorization logic not only programmable and composable, but also mathematically verifiable.

Simple FPJSON examples:

["add", 1, 2] // = 3
["difference", [1, 2, 3], [3, 4, 5]] // = [1, 2]
[["map", ["inc"]], [1, 2, 3]] // = [4, 5, 6]
[["compose", ["map", ["inc"]], ["difference"]], [1, 2, 3], [3, 4, 5]] // = [2, 3]

FPJSON as an authentication layer:

[
  "set:follow", // define a custom query type
  [
    ["split()", [":", "$id", ["=$from_id", "=$to_id"]]],
    ["=$isFromSigner", ["equals", "$from_id", "$signer"]],
    ["mod()", { from: "$from_id", to: "$to_id", date: "$ms" }],
    ["allowif()", "$isFromSigner"]
  ],
]

FPJSON also enables data mutation during the authentication process, effectively acting as a smart contract layer embedded within the database itself. This eliminates the need for external smart contracts when building complex, logic-driven applications.

In fact, we’ve built a fully decentralized Twitter clone using only WeaveDB, with no external contracts involved.

Because FPJSON is fully structured and declarative, it is also extremely LLM-friendly—AI agents can autonomously read, generate, and modify logic to build sophisticated applications on their own.

FPJSON logic is stored directly within the self-contained JSON structure of the database, making both authentication and data mutation fully traceable and mathematically verifiable with zkDB circuits.

JSON Schema

It's essential to set a presice data schema to each dir as otherwise WeaveDB is permissionless and anyone can put arbitrary data.

To validate data schema, WeaveDB uses jsonschema.

const schema = {
  type: "object",
  required: [ "article_id", "date", "user_address" ],
  properties: {
    article_id: { type: "string" },
    user_address: { type: "string" },
    date: { type: "number" },
  },
}