Transfers and Settlement

Every money movement on the rails ends the same way, regardless of whether it started as a payment, an escrow release, or a treasury transfer. The owner signs, the XKOVA Relayer submits, the chain mines the transaction, and XKOVA confirms the result on chain. This page explains that shared lifecycle and the one rule that matters most: mined is not the same as confirmed.

One settlement path

Payments, escrow releases, and treasury transfers all converge on the same back end. The differences are in who signs and how many signatures are needed. After signing, the path is identical: a signed instruction is handed to the relayer, submitted on chain, and watched to confirmation. This is the pattern that makes the rails non-custodial, the owner's signature is the authorization, and a relayer only carries it.

flowchart TD
  A[Signed] --> B[Relayed]
  B --> C[Mined]
  C --> D{On chain success}
  D -- success --> E[Confirmed]
  D -- reverted --> F[Failed]
  D -- unknown --> G[Retry next tick]
  G --> D

The lifecycle states

State	Meaning
Signed	The owner has signed the intent in their own wallet. Nothing is on chain yet.
Relayed	The XKOVA Relayer has submitted the signed instruction on chain and paid gas. It is now in the mempool.
Mined	The transaction has been included in a block. This is necessary but not sufficient. A mined transaction can still have reverted.
Confirmed	The transaction was mined and verified to have succeeded on chain. Only now is the transfer real.

Mined is not success

The single most important rule in settlement is that being included in a block does not mean the transfer worked. A transaction that reverts still consumes gas and is still mined. The on chain success or revert result is a separate signal. XKOVA reads that signal and flips a transfer to confirmed only when the chain reports success. A reverted transaction is marked failed, never confirmed.

Do not treat mined as done. Wait for confirmed. If you only watch for inclusion in a block, you will count reverted transfers as successful. The platform never flips a transfer to a successful terminal state without verifying on chain success first.

When the result is not yet readable

Right after a transaction is mined, the success or revert result can take a few seconds to become readable from chain peers. When that happens the result is treated as unknown, not as success. XKOVA defers and re-checks on its next pass. Unknown is never resolved optimistically, so a momentary read gap cannot promote a transfer to confirmed before the chain has actually confirmed it.

How to track settlement

You have two ways to follow a transfer to its terminal state.

Poll. Read the resource (a payment, an escrow, or a treasury transfer) and watch its state move to a terminal value. Payments and escrows also expose an event timeline you can read for the full sequence of transitions; a treasury transfer has no event timeline, so read the transfer resource itself for its current state.
Subscribe. Register a webhook and receive an event when the transfer reaches a terminal state. This avoids polling and is the recommended way to react to settlement. See Webhooks.

Why settlement can take time

Settlement is asynchronous because the chain is asynchronous. A signed transfer is accepted by the API quickly, but reaching confirmed depends on block production and on the success result becoming readable. Design your integration to treat create and confirm as two separate moments, and to act on the confirmed signal rather than assuming the create call settled the money.

Payments: the sign step that produces a signed transfer.
Treasury: N of M signing before a vault transfer is relayed.
Non-custodial Model: why the owner signs and the relayer only submits.
Webhooks: the events that fire on a terminal settlement state.

Was this helpful?