How many transactions this vault has stored — the database half of the § 3.6 count gate.
Counts utila_transaction, one row per transaction, the unit Utila's
totalSize counts. A vault with no wallets of ours still stores the row.
vaultId is Utila's own vault id; a vault with no row has stored nothing.
Persist one transaction, idempotently.
created: false means the row was already there — the unique constraint on
(utila_vault_id, utila_id) absorbed the write — which is the normal outcome
whenever the webhook fast path and the poll backstop reach the same
transaction.
A transaction that never reached the chain returns created: false with no
row, per § 3.1: it moved nothing and cost nothing, so its absence IS its
state.
vaultId is Utila's own vault id, as the feed and the webhook name it.
Which of these assets/{asset_id} names the registry already describes.
Lets withResolvedUtilaAssets skip asking Utila about an asset an earlier
page registered — a round trip that can only return what is already stored,
and that fails outright on a token Utila does not carry.
Names in, names out, so the caller never has to strip the prefix (§ 4.12).
Every address a wallet has moved funds through, as the vault's stored
transactions name it, first seen first: networkId alone says its chain.
An address that never transacted holds nothing and is absent.
vaultId and walletId are Utila's own ids.
The ids of the vault's wallets its stored transactions name on a transfer,
in id order, after after and at most limit of them. A wallet that never
moved funds is absent. vaultId is Utila's own id.
Writes a Utila transaction and registers the assets it moved.
The raw per-vault record only: wallet balances and history come from
wallet_transaction/wallet_account_transaction, fed by Tatum and Helius.See docs/proposals/UTILA_TRANSACTION_SYNC.md § 3.4.