Raptor's trading routes read Alpaca credentials from env vars (ALPACA_PAPER_API_KEY, ALPACA_PAPER_API_SECRET) set on the Heroku dyno. There is no per-user credential store, no OAuth flow, no "bring your own keys" UI.
At v1.0, Raxx is a single-operator deployment. The question is what shape the "user trades with Alpaca paper" story takes before multi-tenancy is designed.
Three options were considered:
Single operator-owned Alpaca paper account shared by all authenticated users.
Per-user Alpaca paper API key entry in a settings UI (keys stored encrypted at rest).
Block all trading features until #183 multi-tenant design lands.
Decision
Option 1: Use a single operator-owned Alpaca paper account shared across all authenticated users, until #183 designs and ships per-user credential isolation.
The credentials (ALPACA_PAPER_API_KEY, ALPACA_PAPER_API_SECRET) live in Heroku config-vars sourced from Infisical /MooseQuest/alpaca/. No user-facing key entry UI is built. No user credentials are stored.
This is a deliberate v1.0 scoping decision, not an architectural oversight.
Consequences
Positive
Zero per-user credential storage. The "no stored credentials" invariant (ADR 0002) is satisfied trivially — no user credentials exist to store.
Paper-first gating (project invariant) is enforced structurally: the single account is a paper account. There is no mechanism to switch to live because there are no per-user OAuth tokens or live keys.
Implementation is zero net-new code. The existing ALPACA_PAPER_API_KEY env var path in alpaca_integration.py already handles this.
Negative / risks
All authenticated users share the same Alpaca paper portfolio. Position history, orders, and account P&L are not user-isolated. This means two concurrent users would see each other's paper trades.
At v1.0 with a single operator, this is acceptable. The moment a second real user joins, this becomes a UX and privacy problem. This ADR expires when #183 lands.
There is no "user's own Alpaca paper account" story at v1.0. Users who expect a personal paper portfolio will not find one until #183.
Neutral
Raptor's trading route middleware does not check user identity before forwarding to Alpaca. This is fine at v1.0 (single operator). When #183 lands, identity-scoped credential resolution will be added at the service layer, not the route layer.
Alternatives considered
A: Per-user Alpaca paper key entry (user stores their own keys)
Rejected for v1.0. Storing user-supplied Alpaca API keys — even encrypted at rest — touches the "no stored credentials" invariant (ADR 0002). The invariant says "the system must not have the ability to replay a credential." Encrypted-at-rest keys could be decrypted and replayed. The full multi-tenant design in #183 addresses this correctly via OAuth or scoped ephemeral tokens. That design is not ready for v1.0.
B: Disable trading routes entirely until #183
Rejected. Trading is a core value proposition of v1.0. Blocking it entirely in favor of waiting for a multi-tenant design ships zero trading capability. The single-operator paper account is a safe, non-credential-storing interim.