# Security Archer is a non-custodial natural-language transaction engine. Three trust boundaries shape how we approach security: your **keys** (who can sign on your behalf), your **transactions** (what gets validated before a signature), and the **LLM** that interprets your intent (whether the model can ever cause a transaction without you knowing). This page describes how we defend each boundary. Where Archer relies on infrastructure providers, we name them and link to their published security architecture. Where Archer's own code provides the guarantee, we describe the category of defense without exposing internals that would weaken it. ## The wallet environment Archer is non-custodial by design. The platform never holds your private keys, never custodies funds on your behalf, and cannot move funds from your wallet without a signature you authorize. ### Embedded wallets (primary) When you create an Archer account, [Privy](https://www.privy.io/) provisions two embedded wallets - one for EVM chains, one for Solana. These are your **primary** wallets. Swaps, bridges, and other complex transactions execute from them. Privy's wallet model is non-custodial and audited: * **SOC 2 Type II** (April 2026) * Public security audits by Cure 53, Zellic, SwordBytes, and Doyensec * Active HackerOne bug bounty program See [Privy's security overview](https://docs.privy.io/security/overview) for the full architecture. ### Connected wallets You can link external wallets (MetaMask, Phantom, Coinbase Wallet, and others) for three purposes only: authentication, portfolio visibility, and fund consolidation into your primary wallet. Connected wallets sign their own transactions in their own apps - Archer never has signing authority over them. ### Where keys live No private key for an Archer-provisioned wallet is ever held by Archer. Keys are generated, sharded, and used inside Privy's signing infrastructure. The next section describes that architecture. ## How transactions are signed A signature is the moment a transaction becomes irreversible. Archer supports two paths to producing one - and both are designed so that no actor, including Archer itself, can extract a private key. ### In-browser signing (default) For most actions, you sign in the browser. Private key material exists only inside your authenticated session, encrypted with key shares that require the session to reconstruct. Archer's servers never see the key. ### Signing inside the enclave For delegated and headless flows - and for users who opt in to server-resident signing - signing happens inside a **Trusted Execution Environment (TEE)**: an [AWS Nitro Enclave](https://aws.amazon.com/ec2/nitro/nitro-enclaves/) running Privy's signing code. A Nitro Enclave is a hardware-isolated compute environment. Two properties matter for Archer: 1. **Memory isolation.** Enclave memory is inaccessible to the host operating system, to other processes on the same machine, and to Privy itself. Even an operator with full server access cannot read what's inside the enclave. 2. **Cryptographic attestation.** The enclave can prove what code it's running. If the signing binary is tampered with, attestation fails and the enclave refuses to release a signature. ### Key sharding Private keys are never stored in complete form. Privy splits them using **Shamir's Secret Sharing (SSS)**, a cryptographic scheme that divides a secret into shares stored across separate security boundaries. Shares are recombined into a usable key **only inside the enclave**, for **a single signing operation**, and the reconstructed key is destroyed when the enclave returns the signature. ### What this means in plain language *Even an attacker with full access to Privy's servers cannot extract your private key.* The key is not held in Archer's database. It is not held on Privy's servers in usable form. It is reassembled inside hardware-isolated memory, used once, and discarded. See Privy's [security overview](https://docs.privy.io/security/overview) for the full TEE and SSS architecture. ## Transaction safety Before any signature - whether produced in-browser or inside the enclave - every transaction Archer proposes runs through a deterministic gauntlet of checks. These checks are independent of how the transaction was initiated; they apply equally to a transaction you typed manually and one suggested by the LLM. ### Pre-signature checks * **Slippage validation.** Slippage is bounded between 0.1% (minimum) and 50% (maximum), with sensible defaults that scale to your risk profile (Conservative, Moderate, Aggressive). Out-of-range values are rejected before quoting. * **Gas estimation with buffer.** Gas is estimated against current network conditions and increased by a safety buffer to prevent failed transactions on fee spikes. Your wallet must hold enough native token to cover gas - we never let a transaction enter the mempool that's guaranteed to fail. * **Balance and chain compatibility.** Source-token balance is verified before quote. Cross-chain operations check that the source and destination chains are both supported and reachable through our routing providers. * **Transaction simulation.** When the destination chain supports it, Archer simulates the transaction against current state before asking you to sign. Simulation catches reverts, allowance issues, and price-impact problems that wouldn't be visible from a static quote. ### The user is the gate Every transaction is presented as a preview with the source token, destination token, expected amount out, and quoted fees. **Nothing signs without your explicit confirmation.** Archer does not auto-approve transactions, including those proposed by the LLM. There is no "agent autopilot" mode that bypasses this step. ## LLM safety Large language models can hallucinate. They can misread a prompt, invent token addresses, confuse decimals, or confidently produce a transaction that doesn't match what you asked for. Archer treats this as a primary threat - not a footnote - and applies several categories of defense. ### Categories of defense * **Semantic grounding against a curated intent library.** User prompts are matched against a vetted set of supported intent types (swap, send, bridge, price lookup, multi-step). The LLM cannot invent a new intent category at runtime; it can only choose from intents Archer has implemented and tested. * **Retrieval-augmented context from successful past executions.** When the model interprets a prompt, it does so with concrete examples of how similar prompts have been resolved before - grounding interpretation in real, verified transactions rather than statistical approximations. * **Confidence-gated routing.** When a prompt is ambiguous - a misspelled token, a missing chain, a quantity that could mean two things - the system asks you a clarifying question rather than guessing. Low-confidence interpretations never proceed to execution. * **Deterministic transaction preview with simulation.** The output of LLM interpretation is a structured transaction proposal that is independently validated by the deterministic checks described in the previous section. The model proposes; deterministic code disposes. ### The LLM is the interpreter, not the executor No LLM signs a transaction. No LLM has signing authority. The model's role ends when it produces a structured proposal; everything from that point forward is deterministic code and explicit user approval. ## Platform security posture Outside the wallet model and the LLM, Archer's web platform implements the controls you'd expect from a careful product team: ### Authentication * **Explicit allowlist of methods:** email, wallet, Google, Apple * **SMS authentication is disabled** - the SIM-swap attack surface is not worth the convenience * **Passkeys and MFA enabled** at the Privy account layer * **HttpOnly cookies** managed by Privy for session persistence - session tokens are never accessible to JavaScript on the page ### Browser-side hardening * **In-memory token storage only.** Archer's frontend never writes auth tokens to `localStorage` or `sessionStorage`. Persistence is handled exclusively by Privy's HttpOnly cookies. * **Full Content-Security-Policy** restricting script sources, frame ancestors, and connect endpoints * **X-Frame-Options: DENY** to prevent clickjacking * **X-Content-Type-Options: nosniff** to prevent MIME confusion * **Strict-origin-when-cross-origin** referrer policy ### Network and CORS * **CORS allowlist** restricted to Archer's first-party domains (`archerprotocol.com`, `app.archerprotocol.com`, `archer.bot`) * **HTTPS everywhere**, with HSTS enforced at the edge ### Secrets and infrastructure * **Backend-only secrets** are never exposed to the frontend bundle * **Production environment guards** that refuse to start the API if critical secrets are missing * **Infrastructure providers:** Privy (SOC 2 Type II), Supabase, Railway. Infrastructure-layer security inherits from these providers' published controls. ## Responsible disclosure Found a security issue? Email **** with details. We commit to acknowledging your report within 72 hours and will work with you to understand and address the issue. Please do not publicly disclose vulnerabilities until we've had a reasonable opportunity to investigate and remediate. We don't currently run a paid bounty program, but we credit reporters who responsibly disclose, with permission. --- # Agent Instructions: 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://archer-bot.gitbook.io/archer.bot/readme/security.md?ask= ``` 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.