Skip to content
XKOVA MPC

How it works

XKOVA MPC sits between your application and the blockchains. You never handle a private key; you ask XKOVA to hold keys and to sign transactions you authorize, and XKOVA enforces that only you can move the funds.

Keys are never in one place

Section titled “Keys are never in one place”

A blockchain account is controlled by one private key — whoever holds it can move the funds, so it is the thing you must never lose or leak.

XKOVA never assembles that key. Instead, multi-party computation (MPC) generates it as mathematical shares held by separate parties, and produces a signature by having a threshold of those parties compute together. The full private key is never reconstructed — not during key generation, not during signing, not in memory, not in a backup.

The practical consequences:

  • No single point of theft. Compromising one party yields a useless share.
  • No key to hand over. There is no exportable private key, by construction.
  • Rotation without moving funds. The shares can be re-randomized on a schedule; the account’s address is unchanged, so funds and integrations are unaffected.

Who must authorize — tiers

Section titled “Who must authorize — tiers”

A vault’s tier decides where the shares live and who must approve a signature. It is fixed when the vault is created.

TierWho holds sharesWho must authorize a signature
hostedXKOVA-operatedYour end user (via their token) — for embedded wallets your users own
selfXKOVA and youYou — XKOVA cannot sign without your required share
customer_teeYour own trusted environmentYou, running a party in your infrastructure

self is true self-custody: even a full compromise of XKOVA cannot move your funds, because a required share is yours. hosted gives your users a Web2-simple wallet gated by their login. Pick per vault.

Every signature passes policy first

Section titled “Every signature passes policy first”

A vault carries controls that are checked before any share participates — a refused transaction never produces a partial signature:

  • Intent binding — you sign a canonical description of the transaction; XKOVA binds that signature to exactly what it will broadcast, so an operator cannot alter the recipient or amount after you approve.
  • Spend limits — per-transaction and per-day caps.
  • Policy — recipient/asset rules you configure.
  • End-user authorization (hosted) — a valid end-user token per signature.

If any check fails, the transaction is rejected with a reason and no signature is made.

A transaction is asynchronous

Section titled “A transaction is asynchronous”

Moving money is not a single blocking call. When you POST a transaction it returns 202 Accepted immediately, then walks a lifecycle you observe by polling or via webhooks:

created → policy checks → signed → broadcast → confirmed → final
                                             ↘ failed / rejected

Reaching broadcast means the signature was already accepted by the network’s own validity checks; confirmed means it is on-chain. Terminal failures are failed (a broadcast or chain error) or rejected (blocked by policy, limits, or a bad intent).

Everything is auditable

Section titled “Everything is auditable”

Each vault keeps a tamper-evident history — creation, activation, policy and limit changes, and every authorized signing — where each entry is hash-chained to the previous one, so any gap or edit is detectable. See GET /vaults/{vaultId}/audit.

Where to go next

Section titled “Where to go next”