Workflows

Most outcomes are a short, ordered sequence of operations where one step's output feeds the next. The workflow client wraps each of these sequences as a single call: you provide a sign callback for the member's signature, and the client drives the steps and polls for terminal status.

What a workflow call does

A single create is not a finished outcome. A payment must still be signed by the member, cleared by the policy firewall, and landed on chain by the XKOVA Relayer before it is confirmed. The workflow client runs that ordered path for you: it calls each operation in turn, passes each step's output to the next, hands the signing material to your callback, submits the returned signature, and polls the read until it reaches a terminal state.

The member signature happens in the member's own non custodial wallet. The SDK never holds a member key; it only receives the signatures your callback returns. See the Non-custodial Model.

Direct payment send

client.workflows.directPaymentSend({ payment, sign }) wraps create, signing session, member JWT, signature submission, and the poll to confirmed.

const result = await client.workflows.directPaymentSend({
  payment: { to_address: '0x...', gross_amount: '25.00' },
  sign: async ({ signingSession, memberJwt }) => {
    // the member signs TransferIntent + Permit in their in-app wallet,
    // then return the signatures
    return { signature: '0x...', permit_signature: '0x...' };
  },
});
// result.status === 'confirmed'

Token deploy and mint

client.workflows.tokenDeploy('erc721', { ... }) deploys a token and polls until it is deployed; client.workflows.tokenMint(tokenId, { ... }) mints and polls until the mint confirms. For an ERC-20 token, the deploy step also auto-enables it in the workspace token allowlist so it is spendable on payments and treasury; ERC-721 and ERC-1155 tokens are not enabled for the payment rails. See Deploy and Mint.

Off-ramp

client.workflows.offRampInitiate({ ... }) wraps fetching the burn address and creating the off-ramp request. The member then burns stablecoin to the returned address as the off chain step, and your integration polls the off-ramp request for settlement (this workflow returns without polling, since settlement waits on the member's burn). See Funding and Off-ramp.

The underlying flows

Each workflow call corresponds to one documented sequence. The table maps a call to its flow so you can drop down to the raw operations when you need to.

Workflow call	Underlying sequence
`directPaymentSend`	create, signing session, member JWT, member signs, submit signature, poll to confirmed.
`tokenDeploy`	deploy the chosen standard, poll the token until deployed.
`tokenMint`	mint, poll the token until the mint confirms.
`offRampInitiate`	get burn address, create off-ramp request; the member burns and your integration polls the request until settled.

Other flows (escrow create plus claim, treasury N of M transfer, the RWA publish, bind, commit, resolve path, and tenant onboarding) are documented as sequences in Recipes and Examples and can be driven with the low level client today.

Failure handling

A workflow surfaces the same typed errors as the underlying operations: a policy denial from the firewall, a sanctioned address screening result, a signature recovery mismatch, or an on chain revert each throw with a public code. Wrap calls with withRetry to honor retryability and any retry_after. See Errors and Correlation IDs and Rate Limits.

For the client itself and its helpers, see SDK Overview. For the raw operations behind each step, see the interactive reference.

Was this helpful?