submitAndWaitForTransaction calls POST /v2/commands/submit-and-wait-for-transaction. Same synchronous semantics as submitAndWait, but the participant returns transactionFormat-scoped transaction payloads—ideal when you need events without a second lookup.
Receiver: await canton.ledger.submitAndWaitForTransaction
Setup
import { Canton } from '@fairmint/canton-node-sdk';
const canton = new Canton({
network: 'devnet',
provider: '5n',
partyId: 'OWN_PARTY_ID',
});
Minimal example
const result = await canton.ledger.submitAndWaitForTransaction({
commands: [],
transactionFormat: {
transactionShape: 'TRANSACTION_SHAPE_LEDGER_EFFECTS',
eventFormat: {
filtersByParty: {
[canton.getPartyId()]: {
cumulative: [
{
identifierFilter: {
WildcardFilter: { value: { includeCreatedEventBlob: false } },
},
},
],
},
},
verbose: true,
},
},
});
Parameters — SubmitAndWaitForTransactionParams
All fields from SubmitAndWaitParams (commands, commandId, actAs, readAs, disclosure, dedup, etc.—same defaults as submitAndWait), plus:
transactionFormat(optional) —{ eventFormat, transactionShape }describing filters and whether you want ACS-delta vs ledger-effects transaction shape.
Returns — SubmitAndWaitForTransactionResponse
OpenAPI-generated; includes transaction bodies shaped by transactionFormat. Inspect nested structures for transaction, events, and offsets returned by your Canton version.
Errors and pitfalls
Same failure modes as synchronous submits: atomic failure, dedup window behavior, disclosure gaps.
Auth and party
Same OAuth / act-as requirements as submitAndWait.