> 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/concepts/wallet-agnostic.md).

# Wallet-agnostic & challenge auth

Andromeda never requires a user to hold a wallet on a specific chain. Whatever credential a user already controls (an EVM wallet, a Solana wallet, a Bitcoin cold wallet, a Cosmos key, a passkey, an OAuth-linked identity) is enough to authorise an operation. This is a core primitive, not an add-on.

## The challenge flow

Every wallet-agnostic operation has the same shape:

1. **Request a challenge.** You call `POST .../challenge`. Andromeda returns:
   * `challengeBase64`: exactly 32 bytes to be signed.
   * `expectedNonce`: the replay nonce the on-chain program expects next.
   * scheme metadata (which signature scheme the relevant credential uses).
2. **Sign off-chain.** The user signs the 32 bytes with their credential, using whatever signing method that credential supports (a wallet's `personal_sign` / message signing, a passkey assertion, and so on).
3. **Submit.** You call `POST .../submit` with `signatureBase64` and `expectedNonce`.
4. **Andromeda assembles and pays.** It builds the Solana transaction, includes a precompile instruction so the runtime verifies the signature, includes the main instruction, signs only as the gas sponsor, and broadcasts. It returns the transaction signature.

The user never touches Solana, never holds SOL, never sees an RPC endpoint.

## Why 32 bytes

A fixed 32-byte challenge is the largest payload that every supported signing method can sign uniformly, and it is small enough to embed directly in a Solana transaction for precompile verification. The challenge is **domain-separated**: it encodes the operation tag, the dWallet, the nonce, and the member-or-primary slot, so a signature for one operation cannot be replayed for another. See [Domain-separated challenges](/hub/andromeda/on-chain-programs/challenges.md).

## Replay protection

Each flow has its own monotonic nonce on-chain (admin actions, primary recovery, quorum sessions each track their own). `expectedNonce` tells you the current value; the on-chain program rejects a stale one. You always read the nonce from the `challenge` response rather than caching it.

## Discovery vs on-chain schemes

There are two layers:

* **Discovery** (off-chain) proves that a user controls an external wallet, so it can be linked or used. Seven schemes cover Solana, NEAR, Aptos, EVM, Cosmos, Bitcoin and Substrate signing conventions. See [Discovery](/hub/andromeda/guides/discovery.md).
* **On-chain schemes** are what the Quasar programs actually validate when a recovery or policy action runs: Ed25519, Secp256k1 (identified by an Ethereum-style address), Secp256r1, and full WebAuthn. See [Recovery schemes](/hub/andromeda/reference/recovery-schemes.md) and [Precompile validation](/hub/andromeda/on-chain-programs/precompiles.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/concepts/wallet-agnostic.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.