Docs — Secondlayer
Start / Introduction

Decoded chain data, in your own database

Run it beside your node. Backfilled from genesis, reorg-safe, kept current.

Every serious Stacks app eventually needs data that no public API will ever build for it, because the data is specific to your contract. Positions per user. Volume per pool. Whatever your product is actually about.

Today that means writing an indexer. Not the fun part of it either — event ingestion, Clarity decoding, reorg rollback, backfilling years of history, and then operating the thing forever. It's a few weeks to get right and it never stops being yours.

That work is what Secondlayer is. The chain data arrives decoded, backfilled, and reorg-safe, in a database you run. What you write is the part that's actually about your app.

That's the only choice you have to make. The decoding, the reorg handling, and the history are done either way — all that's left is who shapes the read API.

Your situationWhat you writeCalled
Yes — you run tRPC, GraphQL, Rails, somethingA consume() loop: onBatch writes rows into your schema, onReorg rolls them back. secondlayer codegen index emits the mirror schema so your tables can't drift. Serve them however you already serve things.Index
No — and you'd rather not build oneOne TypeScript file: sources, schema, handlers. You get the table and a REST API over it, on your instance.Subgraphs
I want to decode it myselfA consumer over the signed raw firehose: bulk dumps, replay, automatic reorg rewind. This is what Index itself is built on.Streams

Subgraphs gives you a REST API you didn't write. That's the point — and the tradeoff. If you need your own API shape, don't use Subgraphs; use Index and keep your schema.

One global binary; works with bun, npm, or pnpm.

$bun add -g @secondlayer/cli