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. Production partners are interchangeable and configured for the tenant. Every sandbox workspace is pre-enabled with XKOVA's sandbox conversion partner.

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 uses the same signed-intent path as a payment. The configured member wallet produces the required signature, XKOVA verifies the exact signer and payload, and the relayer submits it. See Transfers and Settlement.

Interchangeable conversion partners

Funding and off-ramp do not bind the public API to a single provider. In production, the conversion partner is a swappable adapter configured for the tenant, so XKOVA can move an institution without changing its integration. Examples include Coinbase, Paxos, and Anchorage. In sandbox, XKOVA automatically uses a pre-enabled conversion partner for dUSDC on supported testnets. The same request lifecycle therefore exercises the shape a production integration uses, while no fiat or issuer-controlled USDC moves. 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?