# Turnkey compatibility

Kryard exposes the **exact Turnkey API surface** for secp256k1 EVM signing — same
endpoint paths, same activity envelope, same `X-Stamp` auth — over a KMS-encrypted
key store and an isolated signer.

## Cutover

If you already speak Turnkey, cutover is a single environment swap:

```diff
- TURNKEY_BASE_URL=https://api.turnkey.com
+ TURNKEY_BASE_URL=https://api.kryard.com
```

No client code changes. The public API is Turnkey-shaped; the signer is isolated and
exposes only an internal interface, never the Turnkey surface.

::: info Shapes to expect
Query endpoints use `POST`. The activity response is nested
(`activity.result.<type>Result`) with `{ seconds, nanos }` timestamps — match it;
compatibility beats REST aesthetics at the boundary.
:::

## What's covered

- Private key + wallet/account creation (secp256k1 / Ethereum).
- Raw-payload and EVM transaction signing (EIP-1559 + legacy), Keccak-256.
- Activities with `SHA-256(canonical_json(body))` idempotency, scoped per org.
- Deterministic, fail-closed policy; raw-payload signing off by default outside dev.

## What's deferred

WebAuthn / passkeys / OAuth / OTP auth, raw key export, MPC, and full Turnkey feature
parity are out of scope for the compatibility layer. The embedded-wallet platform
(sub-orgs, auth, sessions, self-custodial MPC) is built on top and under active
development.
