The star schema

The star schema for chainstar. Raw blockchain data to clean dimensional tables in your own warehouse, from one command.

Keys are readable strings that start with the chain, for example ethereum:0xdac17f958d2ee523a2206206994597c13d831ec7 or bitcoin:native, so rows from different chains never collide. Addresses and hashes are as each chain writes them: lowercase 0x hex on Ethereum and Base, Bitcoin addresses and txids as the node returns them, base58 public keys and signatures on Solana. Times are UTC.

The shared columns mean the same on every chain: chain; block_number (the Bitcoin block height, the Solana slot); block_timestamp and date_day; transaction_hash (the Bitcoin txid, the Solana transaction's first signature); and the _id keys. A column that does not apply to a chain is NULL there, as noted below.

fct_transfers

One row per value movement:

• Ethereum, Base: one row per ERC-20 Transfer event.
• Bitcoin: one row per transaction output, coinbase outputs included, in BTC. Bitcoin has no tokens, and a transaction can spend coins from many addresses at once, so no single input is picked as "the" sender. from_address is set only when every input came from the same address, which is the common case; when inputs came from several addresses it is NULL and input_address_count says how many. The coinbase spends nothing: from_address NULL, input_address_count 0. Outputs without an address (OP_RETURN data, bare multisig, pay-to-pubkey, non-standard scripts) are kept with to_address NULL and their script_type; in October 2026 almost half of all outputs were zero-value OP_RETURN outputs.
• Solana: one row per parsed SPL Token or Token-2022 transfer / transferChecked instruction and System Program SOL transfer instruction, top-level or inner (CPI), in successful transactions only. A failed transaction (meta.err set) moves nothing; its fee is still in fct_fees. For SPL tokens, from_address and to_address are the wallets that own the token accounts, and the token accounts are in from_token_account and to_token_account.

amount_raw is text because ERC-20 values are 256-bit integers and SPL amounts 64-bit unsigned, larger than any numeric type DuckDB and Postgres share. Cast it yourself when you need exact arithmetic, for example amount_raw::numeric in Postgres.

Why Solana transfers come from instructions rather than from token balance changes: balance changes (preTokenBalances / postTokenBalances) net out every movement in a transaction and cannot say who paid whom. Checked against real blocks, the parsed instructions account for every token balance change except wrapped-SOL wrapping and unwrapping (syncNative, closeAccount) and the fee that Token-2022 mints with the transfer-fee extension withhold from the recipient: for those mints amount_raw is the amount sent, and the recipient receives less. Token accounts that are created and closed within one transaction appear in no balance list; their mint and owner are read from the initializeAccount instruction that created them.

fct_fees

One row per fee-paying transaction, with what its payer paid.

• Ethereum, Base: every transaction; the execution fee, gas_used × effective gas price. On Ethereum this leaves out the separate blob fee paid by blob (type 3) transactions, and on Base the L1 data fee. cryo does not extract either.
• Bitcoin: every transaction except the coinbase, which pays no fee; the fee is the value of the outputs spent minus the value of the outputs created. A dbt test checks it against the fee the node reports for every transaction. The payer is known only when one address funded the whole transaction; otherwise payer_wallet_id is NULL.
• Solana: every transaction, failed and vote transactions included (is_vote flags validator votes, which are most transactions); the fee is meta.fee (base plus priority fee), paid by the transaction's first account.

fct_swaps

One row per DEX swap (see Swaps and USD prices for the venues): on Ethereum and Base a decoded Swap event, on Solana what one signer gave and got in a transaction that called a known DEX program.

On EVM, trader is whoever sent the transaction, often a bot or a relayer, and one transaction through a router can hold several swaps (one per pool crossed).

fct_token_prices

One row per chain, asset, granularity (hour or day) and UTC bucket; see How prices are derived.

dim_pools

Every Ethereum and Base pool that emitted a swap event, as its contract and factory described it when read (once, at the chain head).

pool_id, chain, pool_address, venue, event_family, factory_address, factory_confirms, is_verified (the factory confirms the pool and is a known venue), token0_address, token1_address, token0_id, token1_id, fee (Uniswap v3-style: hundredths of a basis point, so 500 is 0.05%), tick_spacing, is_stable (Aerodrome), metadata_block_number, first_seen_block, last_seen_block, swap_events

dim_wallets

Every address that sent or received a transfer, or paid for a transaction.

wallet_id, chain, address, is_zero_address, first_seen_block, first_seen_at, last_seen_block, last_seen_at, transfers_out, transfers_in, transactions_sent

"Wallet" here means any address. Some of them are contracts or programs; this release does not tell them apart. On Bitcoin, transfers_out counts inputs spent from the address and transactions_sent the transactions it helped fund, since an output does not always have a single sender. is_zero_address applies to EVM chains only.

dim_tokens

Every asset moved in the loaded data.

token_id, chain, token_address, token_standard, name, symbol, decimals, metadata_block_number, has_metadata, first_seen_block, last_seen_block (the first and last block in the loaded data where the asset moved)

• Ethereum, Base: token_standard erc20; name, symbol and decimals as cryo read them from the contract.
• Bitcoin: one row, bitcoin:native, symbol BTC, 8 decimals.
• Solana: one row per SPL mint (spl-token or spl-token-2022) with decimals from the transactions, plus solana:native for SOL (9 decimals). Mint names and symbols live in separate metadata programs that chainstar does not read, so they are NULL rather than guessed. Wrapped SOL (So111...112) is an SPL mint like any other, kept apart from native SOL.

dim_contracts

Contracts chainstar can identify. In this release that is only the Ethereum and Base token contracts that emitted Transfer events, so it has one row per erc20 row of dim_tokens. Bitcoin has no contracts, and Solana programs are not extracted.

contract_id, chain, contract_address, contract_type (always erc20 for now), first_seen_block, last_seen_block, transfer_events

dim_dates

One row per UTC day from the earliest to the latest loaded block.

date_day, year, quarter, month, day_of_month, iso_day_of_week (1 = Monday), iso_week, is_weekend

Tests

chainstar run finishes with dbt build, which runs these checks and fails the run if any fail: unique and not-null keys on every table, every fact row joining to its date, token and wallet dimensions, every EVM swap joining to dim_pools, every ERC-20 token joining to dim_contracts, accepted values for chains, granularities, methods and confidences, and every USD price and value positive with each price between its lowest and highest observation. Where a column does not apply to a chain (a Bitcoin output with no single sender, for example), its not-null test skips that chain. Two checks warn instead of failing, because the chain can be right and they still fire: a stablecoin whose swaps against other stablecoins put it more than 2% from 1 USD in an hour (at least 3 swaps), and ETH priced more than 2% apart on Ethereum and Base in the same hour (both high confidence).