StaticinstanceThe process default: every write dependency wired, the task queue read
from the temporal namespace at each start.
Fund a quoted escrow: start the create workflow and its 10-day expire sibling.
The sender recalls a held escrow. senderId, when given, must be the
escrow's own sender; the workflow asserts it again.
Claim a held escrow into a ledger account the caller's customer owns. The account's owning identity or organization must carry the escrow's phone.
The recipient binding is what settles a race: it freezes at the first
write, so a second claim into another account, or a claim after the escrow
ended, is NOT_CLAIMABLE and starts nothing. A repeat into the same
account reconciles with the claim already started.
Prepare a new escrow transfer: validate the sender identity, resolve the
funding ledger account, and persist a PENDING row. CFX signs the
withdraw itself inside the create workflow.
Look up a single escrow transfer by id, scoped to the calling customer.
Returns null for both "missing" and "owned by a different customer" —
never leaks existence of another customer's row. Controllers map null
to 404 at the edge.
The recipient (or CFX) declines a held escrow; the hold returns to the sender.
Customer-scoped search. Mirrors the admin search shape minus the
customerIds filter — the customer-scope is applied as a hard WHERE so
no filter combination can leak rows across tenants.
OptionalcreatedAt?: DbTimestampCriteriaOptionalexpiresAt?: DbTimestampCriteriaOptionalidempotencyKeys?: string[]Caller dedupe tokens a create recorded.
Optionalids?: string[]OptionalorderBy?: DbOrderByCriterion<Optionalpage?: numberDefaults to 1
OptionalpageSize?: numberDefaults to 50
OptionalrecipientId?: stringOptionalrecipientPhone?: stringOptionalsenderId?: stringOptionalstatuses?: StoredEscrowTransferStatus[]OptionalupdatedAt?: DbTimestampCriteriaOptionalv1Statuses?: (/v1 values, each matched in both stored forms (API_V2.md §4.5).
Bind a funded (PROCESSING) escrow's recipient, scoped to the calling
customer. The row stays PROCESSING, which /v1 reads as RECIPIENT_SET.
Purely a database write since escrow moved to mintfx holds: the hold names
its target only at commit, so nothing on chain has to learn the recipient
in advance (ESCROW_ON_MINTFX.md §4). The party is resolved here rather
than by the caller so recipient_wallet and recipient_ledger_account_id
are written from one value.
This method owns every precondition the retired updateEscrowRecipient
workflow used to enforce, because the API calls it inline and a caller
that used to get a workflow failure it never saw must get a typed refusal
instead. The binding freezes at the first write: an identical repeat is a
no-op returning the same row, and anything else is RECIPIENT_ALREADY_BOUND
rather than a second destination on a funded hold. /v1's
RECIPIENT_SET is never published, so nothing is announced.
Customer-scoped escrow transfer operations. Reads (
get/search) take acustomerId(the API caller's customer external id resolved fromrequest.customerId) and filter all queries on it so one customer can never read another's data.createresolves the sender's ledger account and persists aPENDINGrow.updatebinds the recipient, the other inline write. Accept, claim, reject and cancel validate against the row and then start the Temporal workflow that submits the transaction, so a caller learns of a refusal before anything starts. Every write needsdepswired.