XKOVA Docs
Non-custodial Model
XKOVA never receives or exports human MPC private-key material. Contracts still require a valid signature from the configured owner address, or the required Safe quorum, before the XKOVA Relayer can settle value. A Thirdweb custom-JWT wallet adds a separate signing-authority trust boundary that externally controlled wallets do not have.
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.
- Sign. The application builds an intent, and the authorized person signs it through the configured wallet as EIP-712 typed data. The resulting owner-address signature is the on-chain authorization. Nothing has moved yet.
- 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.
- 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"]
Key custody and signing authority are different
XKOVA never receives or exports a human wallet's private-key material. That statement does not mean every wallet has the same trust model. An externally controlled EOA signs independently of XKOVA. A Safe requires the configured owner quorum. A Thirdweb MPC wallet keeps its private-key material non-exportable in the provider, while a valid XKOVA custom JWT plus the public Thirdweb client can establish a general provider signing session for that wallet.
| Wallet shape | Signing boundary |
|---|---|
| Externally controlled EOA | The external owner controls the key and signs independently of XKOVA. |
| Thirdweb MPC human wallet | Thirdweb keeps MPC private-key material non-exportable. XKOVA protects the custom-JWT authority and accepts a signature only for the frozen authorized purpose. |
| Multisig Safe | The Safe contract requires its configured quorum. Each owner wallet retains its own custody and signing-session model. |
| XKOVA Relayer | The relayer submits accepted signatures and pays gas. It is not an asset owner. |
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 presented for authorization. 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 configured member wallet produces a transfer-intent signature plus an EIP-2612 permit, and the XKOVA Relayer submits both in one relayed call. Treasury movements use a Safe quorum. Institution-held funds sit in a multisig Safe, and a transfer needs the configured N of M owner signatures before the relayer submits it. If an owner is a Thirdweb MPC wallet, that owner's signing session has the custom-JWT trust boundary described above.
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.