Non-custodial Model

XKOVA is an orchestration layer, not a custodian. Every value transfer is signed by the asset owner in their own wallet, submitted on chain by the XKOVA Relayer, and confirmed on chain by XKOVA. Because the owner signs and the relayer submits, the application never holds a private key, and the transfer still settles on chain.

Sign, relay, confirm

A transfer on XKOVA is never a single write that moves money. It is a three step pattern that separates who authorizes a transfer from who pays gas to submit it.

1. Sign. The application builds an intent, and the owner signs it in their own wallet as EIP-712 typed data. The signature is the authorization. Nothing has moved yet.
2. Relay. The XKOVA Relayer takes the signed instruction, wraps it in the contract's meta transaction entrypoint, submits it on chain, and pays the gas.
3. Confirm. XKOVA observes the on chain result and the resource transitions to a confirmed state. A webhook fires when state changes.

flowchart TD
  M["Member signs intent (EIP-712)"] --> R["XKOVA Relayer submits and pays gas"]
  R --> C["Chain settles transaction"]
  C --> I["XKOVA confirms result on chain"]
  I --> W["Webhook on state change"]

Why the application never holds a key

The owner's signing key lives only in their wallet, typically a Thirdweb in-app wallet bound to a passkey. A passkey cannot leave the device, so the private material never reaches XKOVA. The application brokers the 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.

The mechanics

The pattern is built from public standards, so the cryptographic property is verifiable on chain.

Piece	What it does
EIP-712 typed data	The structured message the owner signs to authorize a transfer. The contract recovers the signer with ecrecover and checks it matches the expected address.
EIP-2612 permit	A signed token approval, so a direct send approves and transfers in one relayed transaction without a separate on chain approval step.
Signed-intent meta transaction	The relayer pattern. The relayer is the on chain sender and pays gas, while the contract recovers and validates the original signer from the signed instruction before acting on it.

Direct sends and treasury

A member to member direct send follows the pattern above: the member signs a transfer intent plus an EIP-2612 permit, and the XKOVA Relayer submits both in one relayed call. Treasury movements use the same idea with a quorum. Institution held funds sit in a multisig Safe (for example a Gnosis Safe), and a transfer needs N of M signers to each sign the Safe transaction before the relayer submits it.

For the money movement product on top of this model, see XKOVA SPS and Transfers and Settlement. For treasury specifics see Treasury, and for the threat model see the Security Model.

Related

See Wallets and Balances for how member wallets are provisioned, and the interactive reference for the signing session and signature submission operations.