acceptTransferOffer

acceptTransferOffer exercises acceptance workflows referencing contract identifiers surfaced listTransferOffers—receiver persona executes POST accepting counterpart obligations atomically.

Setup

import { Canton } from '@fairmint/canton-node-sdk';

const canton = new Canton({
  network: 'devnet',
  provider: '5n',
  partyId: 'OWN_PARTY_ID',
});

Import and receiver

import { Canton } from '@fairmint/canton-node-sdk';

Receiver: canton.validator.acceptTransferOffer.

Minimal example

const res = await canton.validator.acceptTransferOffer({
  contractId: '<offer-contract-id>',
});
console.log(res.accepted_offer_contract_id);

Parameters

contractId (required, string) — Offer contract identifier embedded REST path segments referencing inbound proposal awaiting acceptance.

Returns

accepted_offer_contract_id (string) — Canonical identifier referencing exercised contract correlating ledger acceptance transitions.

Errors and pitfalls

Accepting expired offers yields descriptive HTTP failures—cross-check getTransferOfferStatus.

Auth and party

Bearer token binding receiver wallet identity authorized settling inbound obligations referencing Canton ACS visibility expectations.

Source

src/clients/validator-api/operations/v0/wallet/transfer-offers/accept.ts on GitHub.