Security at Wardcrest

Wardcrest never asks for private keys, seed phrases, signing rights or a wallet connection, and it has no code path that could create or sign a transaction. You give it public addresses (and for Bitcoin, optionally an extended public key) and it reads the chains.

Wardcrest will never ask for a private key, seed phrase or wallet signature. Anyone who does in Wardcrest’s name is attempting a scam.

The worst an attacker could do with a stolen Wardcrest account is read your monitor configuration or silence alerts. Both are covered below: two-factor authentication, roles, an audit log, and email notices to owners when monitoring is removed.

• EVM chains are read through a pool of RPC providers. Each endpoint must prove the expected chain ID before it is used; failing or lagging endpoints are rotated out, and a chain reorganisation retracts the alerts it invalidated and notifies the same channels.
• Bitcoin blocks are fetched raw and checked locally (block hash, proof-of-work against the target and the transaction merkle root) before any transaction in them is trusted.
• Pending Safe transactions come from the public Safe Transaction Service. Wardcrest recomputes each EIP-712 safeTxHash from the decoded fields itself, so a proposal whose displayed contents do not match what would be signed is flagged rather than trusted.
• Prices for balance thresholds and treasury reports are read from Chainlink feeds on-chain, not from a third-party API. Market pages use licensed market data, and major coins are cross-checked against those same on-chain feeds.
• Token names and symbols come from contracts anyone can deploy, so they are sanitised and escaped for every channel: a scam token cannot inject links or formatting into your Slack, Discord or Telegram alerts.

• Passwords are hashed with Argon2id. Repeated failures lock the account temporarily, and every sign-in is rate-limited per address and per network.
• TOTP two-factor authentication with replay protection (a code cannot be used twice) and ten single-use recovery codes stored only as hashes. Turning it on signs out your other sessions. Workspace admins see which members have it enabled.
• Sessions use __Host- cookies (Secure, HttpOnly, SameSite) whose value is never stored, only its SHA-256 hash is. You can see and sign out every session; changing your password signs out all others.
• Password, two-factor and workspace-deletion events email the account owner or the other workspace owners, so a takeover does not go unnoticed.
• Four roles (owner, admin, member, viewer) and an append-only audit log of security-relevant changes, exportable on Team and Business.
• API keys are scoped read-only or read-write, can expire, are shown once and stored only as hashes.

• No analytics scripts, trackers or advertising cookies. The only cookies are the session cookie and, if you use the theme switch, a light/dark preference.
• Deleting a workspace deletes its monitors, alerts, channels and keys. See the privacy policy for the full list.

• A strict Content-Security-Policy with a fresh nonce per request, no third-party scripts, framing forbidden, HSTS, and no inline event handlers.
• Outgoing webhooks are resolved and checked against private and reserved address ranges, then pinned to that address for the request. A webhook URL cannot be used to reach Wardcrest’s internal network.
• Every webhook is signed with HMAC-SHA256 over a timestamp and the body. The docs show how to verify it.
• Links in emails that change something (confirming an address, unsubscribing) open a page with a button instead of acting on the click, so corporate mail scanners cannot trigger them.
• Payments go to a self-hosted BTCPay Server. Its webhooks are signature-checked and never trusted on their own: Wardcrest re-reads each invoice from BTCPay before crediting anything.

Being clear about limits is part of security.

• It detects and warns; it does not block. Pair it with on-chain controls (Safe guards, timelocks, role separation) for prevention.
• Alerts arrive once a block reaches the confirmation depth for its chain. If Wardcrest, a data provider or the Safe Transaction Service is degraded, alerts are delayed: the dashboard and the status page show per-chain health, and an alert is never silently dropped.
• A Safe transaction is only visible before execution if it was proposed through the Safe Transaction Service. Signatures gathered elsewhere are caught when the transaction executes.
• Compromises that never touch a chain (a phished signer, a leaked API key elsewhere) become visible only when they turn into a transaction or a configuration change.

Email support@wardcrest.com with a description, steps to reproduce and the impact you see. We acknowledge reports within three business days, keep you updated until it is fixed, and credit you publicly if you wish.

Good-faith research that follows these rules is welcome and will not be pursued legally: test only against accounts you own, do not access or change other customers’ data, do not degrade the service for others (no volumetric denial-of-service, no spam), no social engineering or physical attacks, and give us reasonable time to fix an issue before disclosing it. Vulnerabilities in BTCPay Server itself should be reported to that project.

Machine-readable contact: /.well-known/security.txt