get_mints and get_burns return them, every get_order answer carries the order’s own, and mint_updated and burn_updated push them as they land. All four use one shape. A burn has the mint’s fields, with previousBurnedQty and burnedAt where a mint has previousMintedQty and mintedAt. tokenAddress is the CET’s on-chain address, and chainId the chain it is on, as get_symbols lists it.
An order that fills in pieces mints in pieces
Each mint covers the shares between what was already minted against the order and what the broker now reports executed:
Sum
amount, never executedQty. executedQty is a snapshot of the order when the mint was decided; adding two of them double-counts.
The memo
A mint’s memo has three fields, separated by colons. On Solana it is written on the mint transaction; on an EVM chain it is not, and the transaction hash links the two instead.traceId: base58 (no 0, O, I or l, never a colon), at most 16 characters. Your reference comes first and is not parsed. Store the traceId: sent back as get_mints traceId, it returns that mint, the cheapest way from a transaction on chain to what it paid for.
- It is not the envelope’s
traceId, which is Securitize’s id for an exchange, for support. - Mints from before the handle existed have no
traceId. - Rarely, a memo starts with the order’s
regulatoryIdinstead of yourexternalRef.
The transaction hash
txHash is the hash of the mint or burn transaction on its chain: 0x and 64 hex digits on an EVM chain, the base58 signature on Solana. Send it back as get_mints or get_burns txHash and you get that mint or burn; an EVM hash matches in either case. On an EVM chain this is the way from a transaction to what it paid for, since the transaction carries no memo.
A mint’s hash is known after the mint lands, not when it lands: usually within a minute. The first mint_updated for a mint usually has no txHash, and a second one carries it. A burn’s hash is known when the burn lands, so its first burn_updated already carries it, unless none was reported for the burn. Mints and burns from before the hash was recorded have none.
A burn’s memo works like a mint’s. It has the same three fields and is written on the burn transaction on Solana.
The executions behind a mint
executions lists the executions a mint paid for, oldest first. They are always whole executions, never a fraction of one, so nothing needs apportioning on your side.
Reconcile on
executionsComplete: true only. A partial list looks exactly like a complete one.
What is reported
Only mints and burns that reached the chain. A mint that was decided but not completed is absent, not reported as pending: those CETs are not in your wallet. A burn that failed, or is not resolved yet, is absent too, and its CETs are still in the redemption wallet.Pushed as they land
mint_updated arrives once a mint’s CETs are on chain, and burn_updated once a burn’s CETs are gone. Either can come minutes after the fill: act on its arrival, not on the fill.
- Read each as a snapshot keyed on
traceId. A mint is usually pushed up to three times: when it lands, again usually within a minute with itstxHashunless the first push already carried it, and again only if its executions completed later. The same snapshot can occasionally arrive twice. A burn is pushed at most twice: when it lands, and again only if its executions completed later. Each push carries the whole record, in no guaranteed order, so overwrite the one you hold rather than adding to it. - Delivery is at most once. Nothing is queued while you are disconnected; read them back after a gap.
Reading them
Filters combine.
limit, from 1 to 200, sets how many come back, newest first; a value out of bounds is refused, not clamped. A filter that matches nothing answers an empty list.