> For the complete documentation index, see [llms.txt](https://shinkalabs.gitbook.io/hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shinkalabs.gitbook.io/hub/andromeda/reference/recovery-schemes.md).

# Recovery schemes

There are two layers of schemes: **discovery** schemes (off-chain proof that a user controls an external wallet) and **on-chain** schemes (what the Quasar programs actually validate when a recovery or policy action runs).

## Discovery schemes (off-chain)

Used to prove ownership of an external wallet so it can be linked or added as a recovery owner. The user signs a challenge using that ecosystem's message-signing convention. An `appId` is required. See [Discovery](/hub/andromeda/guides/discovery.md).

| Scheme              | Ecosystem | Signing convention             |
| ------------------- | --------- | ------------------------------ |
| `ed25519-raw`       | Solana    | raw ed25519 over the challenge |
| `ed25519-near`      | NEAR      | NEP-413 signed message         |
| `ed25519-aptos`     | Aptos     | AIP-62 signed message          |
| `secp256k1-eip191`  | EVM       | `personal_sign` / EIP-191      |
| `secp256k1-adr036`  | Cosmos    | ADR-036 signed message         |
| `secp256k1-bitcoin` | Bitcoin   | BIP-137 message signature      |
| `sr25519-substrate` | Substrate | sr25519 signed message         |

## On-chain schemes

Used by the `rules-policy` program (and the passkey/fhe policies) to validate signatures in a recovery or policy action. Each is verified by a Solana runtime precompile in-transaction. An owner is identified by a canonical 34-byte member slot: `[scheme byte || identifier || zero padding to 34]`.

| Scheme      | Identifier                     | Slot layout          | Where it can be used                           | Covers                                                      |
| ----------- | ------------------------------ | -------------------- | ---------------------------------------------- | ----------------------------------------------------------- |
| `Ed25519`   | 32-byte public key             | scheme + 32 + 1 pad  | primary owner, quorum member, admin signatures | Solana, Sui, NEAR, Aptos, Cosmos ed25519, Substrate ed25519 |
| `Secp256k1` | 20-byte Ethereum-style address | scheme + 20 + 13 pad | primary owner, quorum member                   | EVM, Bitcoin (BIP-137), Cosmos secp256k1, Substrate ECDSA   |
| `Secp256r1` | 33-byte compressed P-256 key   | scheme + 33 + 0 pad  | primary owner, quorum member                   | passkeys in compact raw form                                |
| `WebAuthn`  | 33-byte compressed P-256 key   | scheme + 33 + 0 pad  | quorum member only                             | passkeys with a full assertion (clientDataJSON inline)      |

## Mapping discovery to on-chain

A user proves ownership with a discovery scheme, then enrolls an on-chain owner using an on-chain scheme:

* Solana wallet: `ed25519-raw` discovery -> `Ed25519` on-chain.
* EVM wallet: `secp256k1-eip191` discovery -> `Secp256k1` on-chain (identified by the 20-byte address).
* Bitcoin wallet: `secp256k1-bitcoin` discovery -> `Secp256k1` on-chain.
* Cosmos wallet: `secp256k1-adr036` or an ed25519 account -> `Secp256k1` or `Ed25519` on-chain.
* NEAR / Aptos wallet: `ed25519-near` / `ed25519-aptos` discovery -> `Ed25519` on-chain.
* Substrate wallet: `sr25519-substrate` discovery -> `Ed25519` or `Secp256k1` on-chain (Substrate supports both natively; sr25519 is not validated on-chain).
* Passkey: register the P-256 key -> `Secp256r1` (any slot) or `WebAuthn` (quorum members only).

## Why on-chain is narrower

Runtime precompiles exist for Ed25519, Secp256k1 and Secp256r1, plus enough to validate a full WebAuthn assertion. They do not exist for sr25519, Ristretto, or pure Bitcoin Taproot. Bridging those would require an off-chain attestor, which Andromeda will not introduce. See [Zero attestor](/hub/andromeda/concepts/zero-attestor.md) and [Known limitations](/hub/andromeda/reference/limitations.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://shinkalabs.gitbook.io/hub/andromeda/reference/recovery-schemes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.