Funding and Off-ramp

The rails move stablecoin value. Funding and off-ramp are the two ends that connect that value to the bank. A funding request brings fiat in and turns it into stablecoin. An off-ramp request turns stablecoin back into fiat and pays it out. Both run through a conversion partner, and the partner is interchangeable, chosen per tenant at onboarding rather than wired in.

The two directions

Direction	Request	What it does
In	Funding request	Converts fiat to stablecoin and credits it onto the rails.
Out	Off-ramp request	Converts stablecoin back to fiat and pays it out to the bank.

Each direction is a request you create and then read to completion. Both list with pagination, newest first, and each can be fetched by id to follow its progress.

Funding value in

A funding request represents fiat coming in to be converted into stablecoin. You create the request, the conversion partner moves the fiat and mints or releases the stablecoin, and the value lands on the rails ready to send. From there it flows through Payments, Escrow, or Treasury like any other balance.

Cashing out

An off-ramp request converts stablecoin back to fiat and pays it out. Off-ramp is member burns first: the member's wallet sends the stablecoin to the conversion partner before the request completes. The API exposes the on chain destination address to send to, resolved from the active conversion profile, so the client knows exactly where to sign the outbound transfer. Once the partner has the stablecoin, it dispatches the fiat; the request settles when the receiving bank confirms the credit has posted to the member's account, so expect a window between the partner sending the wire and the request reading as settled.

Because off-ramp burns first, the outbound stablecoin transfer is a signed, non-custodial move like any other on the rails. The member signs it in their own wallet, the same way they sign a payment. See Transfers and Settlement.

Interchangeable conversion partners

Funding and off-ramp do not bind to a single provider. The conversion partner is a swappable adapter chosen per tenant during XKOVA onboarding, so a tenant runs with one partner and XKOVA can move it to another without any change to how your integration calls the rails. Examples of the kind of partner that plugs in here include Coinbase, Paxos, and Anchorage. The orchestration layer presents the same funding and off-ramp shape regardless of which partner is active. The full conversion model is on Conversion and Ramps.

Following a request to completion

Both funding and off-ramp are asynchronous because settlement depends on the partner and, for off-ramp, on an on chain transfer confirming. Create the request, then either poll it by id or subscribe to events to learn when it completes or fails. See Webhooks for event delivery and Errors and Correlation IDs for distinguishing a retryable failure from a permanent one.

Sandbox supports deterministic funding and off-ramp failure scenarios so you can test the unhappy paths before going live. Drive them with the sandbox scenario header on ramp writes.

Conversion and Ramps: the conversion model and partner configuration.
Payments: spending the value once it is on the rails.
Transfers and Settlement: how the off-ramp burn confirms on chain.

For the exact funding and off-ramp operations and their request and response shapes, see the operations list or try them live in the interactive reference.

Was this helpful?