How many transactions this vault has stored — the database half of the § 3.6 count gate.
Counts utila_transaction, not utila_wallet_transaction: the gate
compares against Utila's totalSize, which counts transactions. A vault
with no wallets of ours still stores the parent row, and a transaction
touching three wallets stores three children, so counting children would
disagree with Utila by construction.
Persist one transaction, idempotently.
created: false means the row was already there — the unique constraint on
(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. The child rows are written in the same DB transaction as the
parent, so a present parent implies present children and no child work is
repeated.
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.
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).
Writes a Utila transaction and the per-wallet balance rows it implies.
Mirrors
SolanaAccountTransactionService.createstep for step — onedb.transaction(), the parent insertedonConflictDoNothing, the child rows derived and inserted in the same transaction, chunked so the statement text stays bounded. Two things differ, and both are forced by the custodian:utila_assetis upserted first, because the child rows carry an FK to it. On the Solana side the mint is an inline string with nothing to reference.preBalanceandpostBalance; Utila hands over the amount and nothing else, so the balance is derived at read assum(amount)over the series in chain order — which makes ingest order irrelevant. SeeUtilaAccountBalanceQueryService.See docs/proposals/UTILA_TRANSACTION_SYNC.md § 3.4.