Security Model

XKOVA is an orchestration layer, not a custodian. The core security property follows from that: the owner of an asset holds the only key that can move it, and the XKOVA Relayer can submit a transfer only after the owner has signed it. Compromising XKOVA's infrastructure does not let an attacker move customer funds.

The non-custodial property

Every value transfer is authorized by a signature the owner produces in their own wallet. The application builds an intent, the owner signs it as EIP-712 typed data, and the XKOVA Relayer wraps the signed instruction in the contract's meta transaction entrypoint and pays gas to submit it. The contract recovers the signer on chain and rejects anything that does not match. Because the signature is the authorization, the platform never needs the key. See the Non-custodial Model for the mechanics.

The relayer is the on chain sender and pays gas, but it cannot originate a transfer. Without a valid owner signature, the contract reverts. The relayer moves nothing on its own.

What the platform can and cannot do

The platform can	The platform cannot
Build an intent and present it for signing.	Sign on the owner's behalf.
Submit an owner signed instruction and pay gas.	Move funds without a valid signature.
Apply policy and screening before relaying.	Extract a member's private key.
Pause a token or deny a transfer it controls.	Forge a signature that the contract will accept.

Threat model

Platform compromise. An attacker who controls XKOVA infrastructure still cannot move customer funds, because they cannot produce the owner's signature. The signing key never reaches the platform.
Relayer compromise. The relayer submits signed instructions and pays gas. A compromised relayer can refuse to submit or waste gas, but it cannot author a transfer the contract will accept.
Stolen API key. A tenant API key authorizes server to server calls scoped to one tenant. It can initiate and drive payment workflows up to the point where the member's signature is required, but it cannot complete a move of member funds: the on-chain execution requires the member's EIP-712 signature, which the key cannot forge or bypass. Rotate immediately if a key is exposed.
Stolen member credential. A member access token authorizes actions on behalf of a member, but the wallet key stays in the member's wallet. High impact actions also require a fresh step up proof.
Replayed request. Idempotency keys make a retried write safe: a key reused with a different body is rejected with a conflict error, so a replay can never submit a different operation under a retried key. See Idempotency.

Authorization and governance

Beyond the signature, every mutation is authorized against a single permission registry, and high blast actions are gated by an approval quorum with separation of duties. Every financial or governed mutation records the authority exercised. These controls run in front of the relayer, so a denied or unapproved action never reaches the chain. The posture is secure by default: a fresh workspace is seeded with owner-approval requirements on six high impact actions (governance changes, ownership transfer, policy commits, API key creation, signer changes, counterparty additions), and the gate on governance changes itself cannot be removed. See Roles and Permissions, Policies and Quorum Governance, and the Audit Log.

Auth boundaries

There are two auth boundaries: tenant (via API key) and member (via session). Certain high impact actions additionally require step up re-auth, a fresh authentication proof bound to the session, the specific action, and (for high value transactions) the request body, with a short non extensible lifetime. The full patterns, key formats, and the step up flow are in Authentication.

Secrets hygiene

Never commit API keys to source, and never log the Authorization header. Keep tenant keys on a server or trusted worker, not in a browser.
Each key is shown once at creation; only a prefix and a hash are stored. Rotation returns a replacement once and revokes the old key.
Member wallet keys live only in the member's wallet and are never exposed to the platform or to integrators. See Key Management.

Compliance posture

Items defined by the business rather than by the API (formal certifications, data retention windows, support tiers, and service levels) are available on request and are defined by the business. See Support for how to reach the team.

See Key Management for how keys are held and rotated, Screening and Identity Verification for the compliance controls that run before a transfer, and the interactive reference for the operations behind each control.

Was this helpful?