# Chain coverage

Kryard's custody + signing + relay surface is **multi-chain by stages.** The honest
way to read "support" is per-tier — not as a single boolean, and definitely not as
"the chain appears in an address-format list." This page is the per-tier matrix.

(You may have come from the FAQ's "Which chains does Kryard support?" — the short
answer lives there; this page is the long one.)

## Three tiers

A blockchain is not a single capability. Kryard splits "support" into three tiers:

| Tier | What it means | Who does the rest |
|---|---|---|
| **T1 — Custody** | Kryard derives the chain's address from a KMS-encrypted key, and signs **arbitrary bytes** with that key's curve (no transaction structure, no policy on contents). | the client builds the transaction and broadcasts it itself |
| **T2 — Transaction** | Kryard builds / serializes a chain-native transaction, enforces **policy on the transaction's contents** (sign only what the configured rules allow), and returns the signed payload. | the client broadcasts |
| **T3 — Relay** | Kryard broadcasts, tracks to finality, and sponsors gas — the **managed product**, end to end. | nobody — this is the full surface |

EVM is at **T3**. For every other chain Kryard is at **T1 only**: Kryard can hold
the key and sign bytes you supply, but it does not build a Solana / Tron / Sui
transaction, nor relay one. The matrix below makes that explicit.

## Coverage matrix

| Chain | Curve | T1 — Custody + raw signing | T2 — Transaction signing | T3 — Relay (managed) |
|---|---|---|---|---|
| **EVM** (Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, …) | secp256k1 | ✅ | ✅ | ✅ live on Sepolia testnets (Ethereum / Base / Arbitrum / Optimism / Polygon / BSC) |
| **Solana** | ed25519 | ✅ derive base58 address · `sign raw` with `HASH_FUNCTION_NOT_APPLICABLE` (signs the message bytes directly — Solana's wire requirement) | — | — |
| **Tron** | secp256k1 | ✅ base58check `0x41`-prefix address · `sign raw` with `HASH_FUNCTION_KECCAK256` (Tron hashes like EVM) | — | — |
| **Sui** | ed25519 | ✅ blake2b address · `sign raw` with `HASH_FUNCTION_NOT_APPLICABLE` | — | — |
| **Aptos, Bitcoin, Cosmos, Doge, Stellar, TON, XRP, Sei, Spark** | secp256k1 / ed25519 / P-256 (per native) | ⚠️ address derivation only; raw signing on the curve is available but the wire shapes aren't pinned | — | — |

Rows that say "address derivation only" pass through the public [`/signing/`](/signing/)
`create_private_keys` path: Kryard returns the address; nothing else is asserted.

### What "T1 custody + raw signing" lets you do

For Solana / Tron / Sui today you can:

- Create a private key in Kryard's KMS-encrypted store on the right curve:
  - Solana / Sui — `CURVE_ED25519`
  - Tron — `CURVE_SECP256K1`
- Derive the chain-native address.
- Sign arbitrary bytes through `sign_raw_payload`:
  - Solana / Sui — pass `HASH_FUNCTION_NOT_APPLICABLE` (the signer signs the
    message bytes directly, which is exactly what Solana requires of the
    serialized-message signature).
  - Tron — pass `HASH_FUNCTION_KECCAK256` (same shape as EVM).

After that **you build the transaction and broadcast it yourself.** Kryard is not
part of the broadcast path for non-EVM chains.

### Scope of custody + raw signing on non-EVM chains

- **No transaction-policy enforcement** on non-EVM raw signs. The signer re-checks
  that the payload matches the policy-evaluated input (the EVM path does this), but
  a non-EVM `sign_raw_payload` has no chain-semantic policy on the *contents* of
  what it signs. The raw-payload lane is gated off by default; see
  [`/signing/signing`](/signing/signing).
- **No `sign_transaction` on non-EVM chains.** A `sign_transaction` request that
  declares any non-EVM transaction type is rejected with
  `UNSUPPORTED_TRANSACTION_TYPE` — the signer never silently dispatches non-EVM
  bytes to the EVM path.
- **No relay / sponsor / paymaster** on non-EVM chains. The relay tier — RPC
  clients, nonce management, gas estimation, EIP-1559 + EIP-7702 broadcast — is
  EVM-only end to end. There is no pay-gas-in-any-token, no `sponsorExecute`, no
  4337 paymaster lane for non-EVM chains.

## Stating this honestly

The precise wording for non-EVM chains is **"key custody and raw message signing,"**
not "support." Anything stronger oversells what Kryard actually does for Solana /
Tron / Sui today. `create_private_keys` + `sign_raw_payload` are available; building
a transaction, enforcing transaction-content policy, broadcasting, and gas
sponsorship are not.