> For the complete documentation index, see [llms.txt](https://docs.strikelabs.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.strikelabs.app/api-reference/authentication.md).

# Authentication

Strike identifies you by an Ethereum address. You prove you own it by signing a challenge; in return you get an opaque bearer token. There is no password and no API key to leak.

Public reads — everything under the [info endpoint](/api-reference/info.md) — need no authentication at all.

## The flow

```
GET  /v1/auth/challenge?address=0x…   →  { "message": "…" }
     sign that message with your wallet (personal_sign)
POST /v1/auth/verify {address, signature}  →  { "token": "…", "account": {…} }
     send  x-paper-token: <token>  on every authenticated request
```

### 1. Request a challenge

```bash
curl "https://api.strikelabs.app/v1/auth/challenge?address=0xYourAddress"
```

```json
{
  "message": "Strike: sign in to prove you own this address.\n\nAddress: 0xyouraddress\nNonce: 7f3c…"
}
```

The address in the message is lowercased. Sign the **exact bytes** returned — do not rebuild the string yourself, do not trim the blank line, and do not re-case the address. A byte that differs recovers a different signer.

### 2. Sign it

Standard EIP-191 `personal_sign`. The venue recovers the address with the `\x19Ethereum Signed Message:\n` prefix, so any ordinary wallet signature works.

```javascript
const { message } = await (await fetch(`${API}/v1/auth/challenge?address=${address}`)).json();
const signature = await account.signMessage({ message });
```

### 3. Verify

```bash
curl -X POST https://api.strikelabs.app/v1/auth/verify \
  -H 'content-type: application/json' \
  -d '{"address":"0xYourAddress","signature":"0x…"}'
```

```json
{
  "token": "…",
  "account": { "cash": 10000, "equity": 10000, "positions": [] }
}
```

A returning wallet lands back on **its own balances and positions** — the address-to-account link survives restarts.

Whether a *new* wallet arrives with a balance depends on the venue's funding mode, and that difference is the whole difference between a test venue and a real one. Check `GET /healthz` before assuming either:

* **`paper`** — a wallet signing in for the first time is funded with paper capital, as shown above. None of it is real.
* **`deposits`** — accounts start at **zero**. Cash arrives only from a confirmed USDC deposit into the vault on Arbitrum, and an unknown bearer token is refused rather than funded. See [Custody and the money lifecycle](/protocol/custody.md).

### 4. Use the token

```bash
curl https://api.strikelabs.app/v1/me -H 'x-paper-token: <token>'
```

`Authorization: Bearer <token>` is accepted equivalently.

## Nonces

A challenge is single-use and expires **10 minutes** after it is issued.

The nonce is consumed on `/v1/auth/verify` **whether or not the signature checks out**. Leaving a nonce live after a failed attempt would let a captured signature be replayed against the same challenge, so a failed verify burns it. If you get `bad signature`, request a fresh challenge — retrying the old one returns `no challenge` or `challenge expired`.

## Signing orders

**This token does not authorise writes on a venue holding real money.** Order flow has its own scheme: a wallet approves a **session key** once, and that key signs every write after it. In `deposits` mode a signature is mandatory and an unsigned write is refused outright, whatever token you send.

See [Session keys](/api-reference/session-keys.md), or [Signing](/api-reference/signing.md) for the scheme end to end with golden vectors.

## Tokens

Tokens are opaque bearer strings. Anything holding one is you: it can place orders and read positions. Treat it like a session key.

Tokens live in venue memory. A restart invalidates outstanding tokens, and clients should re-run the challenge flow on a `401`. Your account itself — cash, positions, history — is durable and keyed to the address, not the token.


---

# 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, and the optional `goal` query parameter:

```
GET https://docs.strikelabs.app/api-reference/authentication.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.