Add balances_bitcoin_daily model

[0xBoxer]

Summary

• Adds a new balances_bitcoin_daily incremental model that tracks daily BTC balances per wallet address
• Follows the established forward-fill pattern from stablecoins_tron_balances_from_transfers — the same architecture used across all stablecoin balance models
• Replaces the broken approach in balances_bitcoin_satoshi_day which had a missing satoshi→BTC conversion, bogus "profit"/"total_asset" columns, and unmaterialized views that couldn't execute at scale

How it works

1. UTXO flow extraction — bitcoin.outputs as deposits (credit), bitcoin.inputs as withdrawals (debit)
2. Daily aggregation — Net daily inflow/outflow per wallet
3. Incremental prior balances — On incremental runs, fetches last known balance from {{ this }} to avoid recomputing from genesis
4. Forward-fill gap join — Carries the last known balance forward across inactive days using lead(day) + date spine
5. USD pricing — Proper satoshi / 1e8 * BTC price at the final layer

Output columns

Column	Description
blockchain	Always 'bitcoin'
day	Date
wallet_address	Bitcoin address
balance_satoshi	Cumulative balance in satoshis (forward-filled)
balance_btc	Balance in BTC (balance_satoshi / 1e8)
btc_price_usd	BTC price on this day
balance_usd	USD value of holdings
last_updated	Block time of most recent transaction affecting this balance

Config

• materialized = 'incremental' with merge strategy
• partition_by = ['day']
• unique_key = ['day', 'wallet_address']
• incremental_predicates for partition pruning
• Schema tests: unique_combination_of_columns + not_null on balance_satoshi

Test plan

• Model compiles cleanly (dbt compile --select balances_bitcoin_daily ✅ verified locally)
• CI runs the model against Dune API
• Verify output data quality: spot-check known wallet balances
• Verify incremental runs produce consistent results with full refresh

Made with Cursor

[cursor]

PR Summary

Medium Risk
Adds a new incremental, forward-filled balance table over long date ranges and per-address partitions, which can be costly or incorrect if incremental predicates/date spine joins behave unexpectedly; otherwise it’s isolated to a new model and schema entry.

Overview
Adds a new dbt model, balances_bitcoin_daily, that produces daily per-wallet cumulative BTC balances from bitcoin.outputs (deposits) and bitcoin.inputs (withdrawals), forward-filling balances across inactive days.

The model is incremental/merge partitioned by day with a prior_balances bootstrap for incremental runs, and enriches output with USD valuation via prices.usd plus schema tests (unique_combination_of_columns on day+wallet_address and not_null on balance_satoshi).

^{Written by Cursor Bugbot for commit 150cc7f. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

Comment @cursor review or bugbot run to trigger another review on this PR

[cursor]

Price join may produce duplicate rows

High Severity

The join f.day = p.minute compares a date column with a timestamp column. In Spark SQL this typically casts the timestamp to date, so all price rows whose date matches f.day are returned. If prices.usd has multiple rows per day for BTC (e.g. minute or hourly granularity), the join produces multiple rows per (day, wallet_address), violating the model unique_key and causing merge failures or incorrect data.

 

[cursor]

Zero-balance rows excluded, diverges from reference pattern

Medium Severity

The model filters f.balance_satoshi > 0, which drops the day a wallet empties. The reference pattern in stablecoins_tron_balances_from_transfers and stablecoins_balances_from_transfers keeps zero-balance rows when cast(f.last_updated as date) = f.day so the day of the actual balance change is recorded.

 

[cursor]

Missing null checks on block_date and block_time

Medium Severity

The deposits and withdrawals CTEs do not filter out rows where block_date or block_time is null. Null block_date becomes null day, which flows into daily_aggregated and changed_balances. The forward-fill join d.day >= b.day fails to match when b.day is null, so those transactions are dropped. Transactions with null block_time can produce null last_updated and affect ordering in window functions.