Architecture
back to the landing page
For AI agents · in practice

Agent actions,
on the record.

Chromia runs a full relational database at consensus. That’s what makes agent memory, identity, and every action verifiable and tamper-evident on-chain. Here’s what it unlocks — shipping on mainnet today.

01·What becomes possible

Why agent state and actions are verifiable here.

A relational database at consensus makes agent memory, identity, and every action queryable and tamper-evident on-chain. The same property unlocks games and DeFi that key-value chains can’t hold — three domains, shipping on mainnet today.

01·Games

Fully on-chain worlds, not just NFTs.

What most “on-chain games” actually put on-chain is token ownership. The world itself — inventories, stats, guilds, match history, economy — sits in a centralized database because a key-value chain can’t hold it efficiently.

Before

Before · on a key-value chain

  • Half the game state on-chain (tokens, NFTs). Half off-chain (world, inventories, stats).
  • Players pay gas for every in-game action. High volume means high cost.
  • Guild membership, leaderboards, trade history need external indexers to be queryable.
  • “Fully on-chain” collapses the moment you inspect what that means.
With Chromia

With Chromia

  • Full game state as typed entities: players, items, guilds, quests, matches.
  • Zero gas for players. Act as often as the game demands without per-action cost.
  • One query renders an entire player dashboard. No separate read service.
  • Each game gets its own dedicated chain. Economy is yours. Performance is predictable.
02·AI Agents

Agents with memory, identity, and verifiable history.

Agent platforms need structured memory, persistent identity, and an auditable record of what each agent has done. Key-value chains can’t provide any of those without collapsing into centralized infrastructure.

Before

Before · on a key-value chain

  • Agent memory lives in a centralized database the platform operator controls.
  • Agent identity is an API key somewhere. Impersonation and sybils are easy.
  • Cross-agent coordination requires trusting a central service to broker it.
  • Platforms hit security flaws, spam, and compromised tokens fast.
With Chromia

With Chromia

  • Each agent owns a keypair. First-class on-chain identity, no external registry.
  • Memories persist as relational state. Queryable by topic, time, or relationship.
  • Native pgvector for similarity search: embedding retrieval as a protocol feature.
  • Every post, reply, vote is a signed transaction. Verifiable at consensus.
03·DeFi

Scan state like it’s a database, because it is.

DeFi apps need to scan protocol state in aggregate — positions near liquidation, orderbook depth, pool TVL distributions. On key-value chains, every one of those queries requires external infrastructure.

Before

Before · on a key-value chain

  • Liquidation bots read from The Graph, not the chain itself.
  • Orderbook UIs query a separate indexer service.
  • Yield optimizers, aggregators, and analytics need off-chain infrastructure.
  • Any aggregate view of protocol state = external system + trust model.
With Chromia

With Chromia

  • Scan state directly on-chain. “Positions near liquidation” is one query.
  • Orderbook depth, pool TVLs, open orders — queryable natively with filter / sort / limit.
  • Signed on-chain result. Not a secondary indexer operator’s promise.
  • Each DeFi protocol on its own dedicated chain: predictable, no cross-app congestion.
Also newly possible

Four more categories where the architecture matters.

Social

Feeds, not subgraphs.

Posts, replies, upvotes, reputation — all as relational state with on-chain queries. No subgraph to maintain. The feed query IS the chain query.

BeforeThe Graph + Postgres + GraphQL resolvers + deployment pipeline.
NowOne Rell query, on-chain.
Identity & Reputation

Reputation as queryable state.

On-chain identity is an entity, not just an address. Attributes, attestations, scores, history — all typed, all queryable. The reputation system IS on the chain.

BeforeAddress + off-chain reputation service + attestation indexer.
NowQueryable entities with foreign keys.
Real-World Assets

Rich metadata without hacks.

Tokenizing real-world assets demands structured metadata: legal frameworks, ownership chains, transfer conditions. Relational schemas handle this the way they were designed to.

BeforeToken standard + IPFS metadata + centralized legal DB.
NowEvery attribute as a typed column.
Enterprise / B2B

Audit trails that are actually auditable.

Supply chain, healthcare, finance — domains where structured data, audit logs, and referential integrity aren’t optional. Chromia gives them a database with consensus guarantees.

BeforePrivate chain + off-chain database + manual reconciliation.
NowOne system. Structured. Verifiable.
02·Why it works

Most dapps run on two stacks, not one.

What unlocks all of the above is a specific architectural difference. A typical app on a key-value chain needs the chain itself plus an off-chain indexer that listens to on-chain events and rebuilds queryable state elsewhere. That second system is where your frontend actually reads from.

Two-stack

Key-value chain

  1. 01User signs a transaction. Writes state + emits events.
  2. 02Chain records it. State updated, but readable one record at a time by primary key.
  3. 03Off-chain indexer listens to events. The Graph / subgraph / custom Postgres.
  4. 04Indexer rebuilds queryable state. Maintained separately from the chain.
  5. 05Frontend queries the indexer — not the chain itself. Trust layer is separate.
Systems2
Trustsplit
Query pathindirect
One-stack

Chromia

  1. 01User signs a transaction. Operation updates typed entities with relationships.
  2. 02Chain commits the state. Stored as native relational tables.
  3. 03Frontend queries the chain directly. Filter, sort, project, join. SQL-like.
  4. No off-chain indexer. The chain is the query engine.
  5. No event bus to maintain. Events are optional, not structural.
Systems1
Trustunified
Query pathdirect
03·Concretely, in code

One query,
two stacks.

Consider a deliberately boring feature in a social app. Here’s what it takes to build it on each kind of chain.

The featureShow me the 20 most-liked posts from the last 7 days.”

On a key-value chain

Solidity + The Graph

Three separate systems: contract, subgraph, frontend. Each with its own deployment, tooling, and failure modes.

01 / 03Feed.sol · contract
contract Feed {
  struct Post {
    uint256 id;
    address author;
    string content;
    uint256 likes;
    uint256 timestamp;
  }
  mapping(uint256 => Post) public posts;

  event PostCreated(uint256 indexed id, address author);
  event Liked(uint256 indexed postId);

  function like(uint256 postId) external {
    posts[postId].likes++;
    emit Liked(postId);
  }
}
02 / 03schema.graphql · subgraph
# off-chain indexer, separate service
type Post @entity {
  id: ID!
  author: Bytes!
  likes: BigInt!
  timestamp: BigInt!
}

# + mapping.ts: handle PostCreated,
#   handle Liked, write to Postgres
# + subgraph.yaml: deploy config
# + separate GraphQL endpoint
03 / 03frontend query · graphql
const query = gql`
  {
    posts(
      where: { timestamp_gt: ${weekAgo} }
      orderBy: likes
      orderDirection: desc
      first: 20
    ) { id author likes content }
  }
`;

// hits indexer endpoint, not the chain
// trust model: whoever runs the indexer
Codebases3 (contract · subgraph · client)
Infrastructurechain + indexer DB
Trustchain + indexer operator
User gasper transaction

On Chromia

Rell · one file

One module defines the entity, the write operation, and the query. The frontend queries the chain directly.

01 / 01feed.rell · full backend
// entity · typed, queryable, persistent
entity post {
  key id: integer;
  index author: pubkey;
  mutable likes: integer = 0;
  content: text;
  timestamp;
}

// signed write
operation like(post_id: integer) {
  update post @ { .id == post_id }
    ( likes += 1 );
}

// native on-chain query
query top_posts(since: timestamp) =
  post @* { .timestamp > since }
    ( .id, .author, .likes, .content )
    sort_desc .likes
    limit 20;
frontend · direct to chain
const posts = await client.query(
  'top_posts', { since: weekAgo }
);

// hits the chain directly
// trust model: the chain itself
// no separate service to operate
Codebases1 (rell module + client)
Infrastructurechain only
Trustchain
User gaszero (app sponsored)
04·Properties

What actually changes,
row by row.

Reference table. Every property that differs between a key-value chain and Chromia’s relational architecture.

PropertyKey-value chainChromia
Storagebytes32 → value mappings. Application defines structure off-chain.Typed entities with key, index, and foreign keys. Schema enforced at consensus.
ReadsOne record at a time, by primary key. No filtering, sorting, or joining.Filter, sort, project, join. @* relational operator, SQL-like.
RelationshipsTracked manually in contract code. Easy to get wrong.Foreign keys are a first-class language feature. Integrity enforced.
IndexingExternal. The Graph, custom Postgres, or a bespoke indexer you run.Native. Indexes are part of the entity schema.
EventsRequired for queryability. Indexer depends on them being emitted correctly.Optional. The relational state is the source of truth.
ToolingSolidity + subgraph + ABI + GraphQL schema + mapping handlers.Rell. One file, one language.
Complex statePainful. Requires off-chain infrastructure to be useful.Natural. The chain itself is a query engine.
User gasPer transaction. Scales with activity.Zero. Hosting is sponsored by the application.
Trust modelChain for state, indexer operator for reads.Chain for both. Unified.

The data security layer for AI agents.

Persistent memory, signed identity, and a tamper-evident record of every action. Build agents anyone can trust — and prove it.