Back homeIndustry

Crypto & web3

Go from decoded chain events to production dashboards without stitching together a queue, a cache and three databases.

The problem

Where the usual stack breaks

01
Web3 data teams inherit the hardest ingestion problem and a strict correctness bar at once: events arrive out of order and get re-delivered, entity state has to be reconstructed from them, and prices have to be derived from many markets.
02
The usual answer, an indexer plus a warehouse plus a cache, drifts out of sync and answers the same question two ways.
03
A single engine that folds events into entity state, orders writes by declared coordinates rather than arrival, and derives prices continuously turns the pipeline into a schema.

Where NYXDB fits

Use-case journeys

On-chain analytics

Events become versioned entity state inside the engine, one slice per producer.

Blockchain & on-chain analytics

DEX & market data

Market state in keyed tables, followed live as swaps land.

Market data & trading analytics

On-chain risk & compliance

Per-address state kept current and enriched at processing time, for screening and scoring.

Fraud & risk

Architecture

How NYXDB fits crypto & web3

Decoded events land in one table; transformations fold them into slices of versioned entity tables; a weighted fold derives each token’s price from its markets; AS OF COMMIT rereads any past snapshot.

01
Ingest
Decoded events arrive through SQL, write batches or native bulk frames.
02
Fold
Entity state stays current on its own, with CREATE TRANSFORMATION … INTO … ATTRIBUTE GROUP.
03
Derive prices
A token’s price is one fold output: SUM(price * liquidity) / SUM(liquidity) per token.
04
Serve
Dashboards read keyed state; STREAM SELECT follows it live.

In practice

Representative query

The examples use the same two tables on every page. See the SQL reference for full syntax.

Activity per balance, kept current by a transformation

CREATE TRANSFORMATION balance_activity INTO balances ATTRIBUTE GROUP activity AS
SELECT
  chain_id,
  recipient AS address,
  token,
  COUNT(*) AS transfer_count,
  MAX(transferred_at) AS last_transfer_at,
  MAX(_index) AS activity_index
FROM transfers
GROUP BY chain_id, recipient, token;

Capabilities

What you get out of the box

In-database folds

Transformations replace the external indexer’s state layer.

Versioned state

Every accepted version is kept, and readable at any commit with AS OF COMMIT.

Arithmetic over aggregates

Weighted prices as one fold output.

Multi-chain keys

Composite primary keys such as (chain_id, address).

Learn more

Attribute groups

Several producers per row.

CREATE TRANSFORMATION

Grouped folds.

Versioned tables

AS OF COMMIT reads.

From events to dashboards, one engine

Explore on-chain analytics or run a node.

Get startedRead the docs