The precomputed row, at the same grain as solana_account_transaction: one
per wallet per asset per transaction.
Where this inverts Solana's table rather than copying it. There, the RPC
gives pre_balance and post_balance in base units and amount is
post_balance - pre_balance. Utila gives a normalized amount and no
balances, and the balance is derived at read as sum(amount) over the
series in chain order (§ 3.8) — so nothing balance-shaped is stored.
Materializing one would make the stored value depend on insert order, which
the chain-native ordering columns already answer without it.
See docs/proposals/UTILA_TRANSACTION_SYNC.md § 3.2, § 3.4 for the writer,
and § 3.8 for the read.
The precomputed row, at the same grain as
solana_account_transaction: one per wallet per asset per transaction.Where this inverts Solana's table rather than copying it. There, the RPC gives
pre_balanceandpost_balancein base units andamountispost_balance - pre_balance. Utila gives a normalized amount and no balances, and the balance is derived at read assum(amount)over the series in chain order (§ 3.8) — so nothing balance-shaped is stored. Materializing one would make the stored value depend on insert order, which the chain-native ordering columns already answer without it.See docs/proposals/UTILA_TRANSACTION_SYNC.md § 3.2, § 3.4 for the writer, and § 3.8 for the read.