Operator Onboarding

The console takes a new operator from signup to a first confirmed payment along one path: sign up, follow the Login Link, pick how you want to use XKOVA, choose your tokens, then work a short checklist. This page walks that path in order so you know what each screen asks and why.

The onboarding path

Onboarding is a sequence, not a settings page. Each step unlocks the next, and the last step lands you on a working integration. The flow looks like this.

flowchart TD
  S["Sign up"] --> L["Login Link or one-time code"]
  L --> F["Intent fork: pick a direction"]
  F --> T["Pick your tokens"]
  T --> C["Five item checklist"]
  C --> Fu["Fund the member wallet"]
  Fu --> P["First confirmed payment"]

1. Sign up

Create a workspace from the console signup form. You provide an email, an organization name and type, and accept the terms. Signup provisions a sandbox workspace and a first operator. New workspaces start in a pending setup state, so the network is not pinned until you make a choice on the next screen.

Sandbox is the default. Sandbox API keys are prefixed xkv_test_. You move to production later through a separate production access step in settings.

2. Follow the Login Link

The first operator must sign in with the Login Link or the one-time code sent by email before doing anything else. This proves control of the email and establishes the operator session. After sign in, the console routes a pending setup workspace to the intent fork rather than the dashboard.

3. The intent fork

The first screen asks one question: what do you want to do with XKOVA? Pick one to continue. You can change direction later.

Choice	What it sets up	Where it lands you
Move money	The rails product: payments, treasury, and escrow.	The dashboard.
Create my own token	The tokenization engine, ready to deploy a token.	The create token wizard.
Just exploring	An empty sandbox workspace to look around.	The dashboard.
Try the demo	A shared, populated demo tenant that resets on a schedule. This does not set up your own workspace.	The demo chooser.

Choosing one of the first three pins the sandbox network one time, flips the workspace from pending setup to active, and records your intent. The call is idempotent, so a retry is safe.

4. Pick your tokens

Next you choose which tokens your workspace can move. Only enabled tokens flow through your workspace. The sandbox list shows test tokens minted from XKOVA operated faucets on Avalanche Fuji, with a common stablecoin preselected. Production tokens appear as coming soon until the mainnet rollout. Pick at least one and continue. You can change this later in settings.

5. The five item checklist

The dashboard shows a checklist of the five backend objects that stand between a fresh workspace and a confirmed POST /v1/payments. Each row links to the page that completes it, and the card disappears once all five are done. After the checklist clears, the dashboard becomes an at-a-glance summary: KPI tiles, a recent-activity feed, and the open compliance queue, each drilling through to its own area.

Item	What it is	Where
Create an API key	A test prefix key for your backend's server to server calls.	Settings, API keys
Enable a token	Add a deployment to the sandbox allowlist so it can move.	Settings, workspaces
Commit a fee schedule	Payments are rejected until a committed schedule prices the send.	Settings, fee schedules
Provision an account	An account holder your members act as. Your backend can create these just in time on member sign in.	Account holders
First payment	The milestone: a payment signed by the holder, relayed by the XKOVA Relayer, confirmed on-chain.	Payments

One checklist item is governance held on a fresh workspace: the first API key creation returns a pending approval rather than executing immediately. The console shows a held notice; the owner attests the request under Governance, Approvals, and re-submitting the same form completes the step. (Committing the value-movement authorization policy, a separate configuration step outside this checklist, is held the same way; committing a fee schedule is not.) This is the seeded secure default described in Policies and Quorum Governance.

6. Fund the member wallet

Provisioning an account holder and deriving that member's wallet records an on chain address but moves no value. A freshly derived wallet is empty, so before the member can send anything it needs a stablecoin balance to send. Gas is not the blocker: the XKOVA Relayer pays gas for every signed transfer, so a fresh wallet never needs a native balance of its own. What stands between a derived wallet and a first send is funding it with the token you enabled.

This is the derive to fund to pay seam. A member wallet is derived on first sign in, through the challenge, sign, and register handshake in Wallets and Balances. You fund that address. Only then can the member sign a payment that settles.

Fund the wallet with a funding request. POST /v1/funding-requests credits stablecoin to the member's wallet, keyed by account_holder_id with the wallet as its destination_address, and returns a request you follow to settlement. In sandbox, set the X-Ramp-Profile: faucet header to mint test USDC on Avalanche Fuji straight to the wallet; the faucet settles synchronously in one on-chain transaction, so the balance is spendable right away. The faucet is capped per destination wallet per day. Like every funding request, it takes an Idempotency-Key so a retry never double funds.

A funding request moves through pending_compliance, pending_issuance, and settled, or failed if it cannot complete. Once it settles, the funded balance appears on the member's wallet, which XKOVA keeps in sync with the chain by reconciliation rather than a live read on every request. The wallet now has value to send. See Funding and Off-ramp for the funding request in full and Sandbox Scenarios for the faucet and the deterministic ramp outcomes.

7. Your first payment

Once a token is enabled and a fee schedule is committed, you can create a payment. The holder signs the intent in their own wallet, the XKOVA Relayer submits it and pays gas, and XKOVA confirms the result on-chain. When the first confirmed payment lands, the checklist clears and onboarding is complete. For the mechanics of the signed transfer, see the Non-custodial Model.

For the developer path to the same first call, see the Quickstart. For the console areas you will use next, see Payments, Treasury, Tokens and Assets, Compliance, and Settings and Branding.

Was this helpful?