A Utila service-account JWT for vaultId, cached until shortly before it
expires.
The cache is not an optimisation detail: every call site mints a token per
request, and under KMS that would be a kms:Sign network round trip on
every Utila API call. It is keyed by vault because the identity is — two
vaults mean two subs and therefore two tokens.
Initiate a Solana transaction via Utila MPC signing.
Submits a serialized Solana transaction for signing by the Utila cosigner. By default, Utila will replace the blockhash with a fresh one and broadcast the transaction after signing.
OptionaldesignatedSigners?: string[]OptionalexternalId?: stringClient identifier for workflow correlation. Must be unique per vault.
Optionalnote?: stringA note visible to all vault members
Optionalpriority?: "HIGH" | "LOW" | "NORMAL"Optionalpublish?: booleanIf true, Utila broadcasts after signing. Default: true
Base64-encoded serialized VersionedTransaction
OptionalreplaceBlockhash?: booleanIf true, Utila replaces the blockhash before signing. Default: true
OptionalrequestId?: stringUUID for Utila-side idempotency (60-minute deduplication window)
One page of a vault's transactions.
Deliberately a single page rather than an exhausting iterator: the caller that walks the whole feed has to persist each page before requesting the next one (balances are carried forward, so a page dropped on the floor is a hole in the arithmetic), and that ordering belongs to the caller's transaction, not to the client.
includeReferencedResources is always on. The response's
referencedResources / referencedAddressesInfo siblings are what resolve
an asset's decimals and an address's owning wallet with no second call, so
a page fetched without them cannot be persisted.
See docs/proposals/UTILA_TRANSACTION_SYNC.md § 3.5 and § 3.6.
Optionalfilter?: stringUtila's filter grammar, e.g. external_id("order-123") or
state(CONFIRMED). See
https://docs.utila.io/reference/filtering — the supported fields are
create_time, state, spam, from_wallet, to_wallet,
pending_user_approval, asset and external_id.
OptionalorderBy?: UtilaTransactionOrderByOptionalpageSize?: numberUtila returns at most 50 when unset, and may return fewer than asked for
— so nextPageToken, never a short page, is what says the feed is
drained.
OptionalpageToken?: stringThe previous page's nextPageToken.
Cast a vote on a transaction request.
A transaction request must collect its required approving votes (while in
AWAITING_APPROVAL) before it advances to AWAITING_SIGNATURE and becomes
eligible for co-signer signing. Voting APPROVE on a request that is no
longer awaiting approval is rejected by Utila.
The full asset records behind a set of
assets/{asset_id}resource names.The second call
includeReferencedResourceswas supposed to make unnecessary — and does, for almost every page. Not every page: vault29a162977e9e's third backfill page nameserc20.avalanche-c-chain-mainnet.0x49D5…in a transfer and ships a 12-assetreferencedResourceswithout it, so the walk stalled on a transaction whose decimals nothing could resolve.This is therefore the fallback, never the path: the ingest asks Utila for exactly the assets a page referenced and its own map left out. Guessing decimals instead would write a plausible balance, which is the failure UTILA_TRANSACTION_SYNC.md § 3.3 exists to prevent.
On the transaction client rather than an asset client of its own because transaction ingest is the only caller and both of its call sites — the poll activity and the webhook consumer — already hold this one.
vaultIdbuys nothing but the bearer token; the endpoint itself is global.Returns what Utila can describe, and does not fail because it cannot describe everything. Utila rejects the WHOLE batch when a single name is absent from its catalogue —
asset not found: [erc20.avalanche-c-chain- mainnet.0x49D5…], which is WETH.e, a token it does not carry even though it carries WAVAX on the same chain. Throwing there would be the wrong gate in the wrong place: § 4.10 makes theutila_assetFK the guarantee, so thatUtilaTransactionService.upsertAssetscan still resolve an asset a human registered or an earlier page already stored — both invisible to this endpoint. An asset that nothing can resolve still fails, loudly, at the FK.