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, then work a short checklist. Networks and assets appear automatically. 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 --> C["Four 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 strict sandbox and production workspace pair plus a first operator. New workspaces start in a pending setup state until you record the product intent on the next screen. This lifecycle does not select a network.

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

The sandbox firewall starts in screen-and-cap mode. A newly approved production workspace starts completely locked and cannot send value until institution staff commit explicit production rules.

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. Management Console entry uses fixed demo staff; Plover offers branded email sign-in and Quick Demo.	The demo chooser.

Choosing one of the first three records your intent and flips the workspace from pending setup to active. The call is idempotent, so a retry is safe. It accepts no network or token selection.

4. Review automatic availability

GET /v1/chains/available lists every active network applicable to the workspace, and GET /v1/workspace-tokens lists its active external and workspace-issued assets. There is no onboarding choice or settings toggle. An asset can be visible without being eligible or certified for every payment rail, so select an exact certified flow when creating an operation.

5. The four item checklist

The dashboard shows a checklist of the four backend objects and milestones 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 four 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
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 payment asset selected for that operation.

This is the provision to fund to pay seam. A successful member binding creates or resumes the canonical wallet lifecycle described in Wallets and Balances. Once readiness returns the wallet address, 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, request dUSDC on Avalanche Fuji or Base Sepolia. XKOVA automatically routes the request through its sandbox conversion partner, mints real on-chain demo tokens to the destination, and settles the normal funding lifecycle. Do not send a ramp-profile header. The partner is capped per destination wallet per day. Like every funding request, the call takes an Idempotency-Key so a retry never double funds.

Sandbox also exposes Circle Testnet USDC on each supported testnet. It is a separate issuer-controlled token and is never substituted for dUSDC. Acquire it from Circle's faucet or use a pre-funded test wallet. Circle publishes the canonical contracts in its USDC contract-address list. Both assets use six decimals; GET /v1/workspace-tokens returns their issuer and asset identity so your integration can distinguish them by chain and contract address. For dUSDC, sandbox_faucet_contract_ref returns the exact public faucet contract for the selected chain.

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 test funding and the deterministic ramp outcomes.

7. Your first payment

Once a fee schedule is committed, select a rails-eligible asset whose direct-send flow is certified and 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?