XKOVA Docs
Key Management
There are several kinds of key on XKOVA, and they are deliberately separated. Member wallet keys move value and stay with their owners. Treasury moves need several independent signers. The XKOVA Relayer only submits instructions the owner already signed, so it can never originate a transfer. API keys authenticate integrators and are shown once, then only ever rotated.
The kinds of key
| Key | Held by | What it can do |
|---|---|---|
| Member wallet key | The member, in their own wallet via the wallet provider. | Sign transfers that move the member's value. Never leaves the wallet. |
| Treasury Safe signer keys | Each treasury signer, in their own wallet. | Each signs a Safe transaction; N of M are needed to move treasury funds. |
| Integrator API key | The integrator, on a server. | Authenticate API calls scoped to one tenant. Cannot move funds without a member signature. |
Member keys stay with the member
A member's signing key lives only in their wallet, provisioned through the configured wallet provider and typically bound to a passkey on the member's device. A passkey cannot leave the device, so the private material never reaches XKOVA or the integrator. The application brokers the signing ceremony with short lived tokens and submits the signed result, but it never sees the key. This is what makes the rails non custodial by construction. See the Non-custodial Model and Wallet Providers.
XKOVA infrastructure cannot move your funds
The XKOVA Relayer is the on chain sender and pays gas, but it only submits instructions the asset owner already signed. It cannot originate a transfer: the contract recovers the owner's signature on chain and reverts anything that does not match. The authorization is the owner's signature, not anything XKOVA holds, so a compromise of XKOVA's infrastructure cannot move your funds. See the Security Model.
API keys: issued once, then rotated
- Shown once. A new API key's secret is returned only at creation, and a rotated key's replacement secret is returned only by the rotate call, matching the create-time behavior. Only a prefix (visible in the console) and a hash are stored, so the full secret is never shown again or logged. On a fresh workspace the first creation is governance held pending owner attestation; the approved re-submission is the call that returns the secret. See Policies and Quorum Governance.
- Test versus live. Test keys are valid only against the sandbox; live keys are valid only against production after production access is approved.
- Rotation. Rotating a key returns a single replacement, and the old secret stops verifying immediately; there is no grace window for API keys (webhook signing secrets keep one, API keys do not). Rotation is a step up action, so it requires a fresh authentication proof.
- Revocation. Revoking a key makes it invalid on the next verification. Deleting a key is a cleanup step that only works after it has been revoked.
- Scoped grants. A key carries roles, and additional role grants can be attached or revoked without rotating the secret, with a cascade on revoke. See Authentication.
Webhook signing secrets
Each webhook endpoint has a signing secret used to sign deliveries. Rotating it issues a new secret while a grace window keeps the old one valid, so you can verify with both during the cutover and switch over without dropping events. Secret rotation is a step up action. See Webhooks.
Secrets are not exposed
- Member wallet keys are never exposed to XKOVA or to integrators.
- API key secrets are shown once and never returned again; only a prefix and a hash persist.
- The Authorization header is redacted from logs; mirror that practice in your own code.
- Rotate immediately if any secret is exposed, using the rotate and reissue flow.
Related
See Authentication for key formats, rotation, and the step up flow, Wallet Providers for how member wallets are provisioned, and the Security Model for how these keys fit the threat model.