Security is not a feature we bolted on. It is the reason Alverium is a local-first desktop application instead of a browser tab. This page explains how we protect your keys, your strategies, and your capital, how far each control actually reaches, and how to report a vulnerability if you find one.
This page is a disclosure, not an agreement. The documents you accept are the Terms of Service, the Privacy Policy, and the Risk Disclaimer.
Local-First by Design
The most sensitive things you touch in Alverium never reach our servers. Exchange API keys, wallet private keys, trade history, open positions, strategy source, and backtest results live on your machine and nowhere else. We cannot read them because we never receive them. A breach of our infrastructure cannot expose data we do not hold.
Two exceptions, named rather than folded into the blanket. If you use cloud model training, or the managed cloud path for Alverium Sage, then the data required for that job or that turn reaches our infrastructure — because it has to. And where an on-chain feature stores encrypted content off-chain, we may participate in the key-management arrangement that governs access to it. Those are the boundaries; the Privacy Policy sets out what happens inside them.
Key and Secret Storage
- OS credential store. Exchange keys and secrets are held in your operating system's native secure credential store, not in application files.
- Layered encryption. Secrets are wrapped in layered encryption and released only to the process that needs them, only when it needs them.
- Key isolation. Credentials for one venue are never exposed to code operating another. A plugin cannot read a key it was not granted.
- Signing separation. The component that decides what to do and the component that holds signing keys are separate processes. The interface holds neither and cannot override either.
- Encryption at rest and in transit. Local data is encrypted at rest with strong, industry-standard encryption (AES-256), and anything that does leave your machine travels over modern TLS.
Strategy Execution Safety
Automated execution is the highest-risk surface in the product, so it is gated by default, not by opt-out.
- Capability declarations. Every strategy package declares up front what it can read, write, and execute. Nothing is implicit.
- Observe, then simulate, then live. Strategies start in observe mode (monitoring only). You promote to simulate (virtual capital), and only then to live, which requires explicit confirmation.
- Arm, then confirm. Entering live execution takes a deliberate two-step gesture with a default-off toggle. The software can propose; it does not sign without you.
- Policy gates and kill switches. Live execution is bounded by policy limits, and per-strategy and global kill switches are provided to halt it.
How far the kill switch reaches, stated honestly. A kill switch is an instruction that still has to reach a venue, and that venue still has to act on it. Coverage varies by venue and asset class, and no control we ship can reach a position at a venue our software cannot connect to at that moment — for example during an outage at that venue, or where your credentials have expired. Treat the kill switch as a fast way to issue the instruction, not as a guarantee of exit. The Risk Disclaimer covers this.
Plugin Security Model
Plugins run at one of three privilege levels:
- Sandboxed plugins run fully isolated with no ambient authority. This is the default and the majority.
- Elevated plugins request specific capabilities behind explicit permission gates that you approve.
- System plugins are signed by Alverium and reserved for first-party functionality.
The level a plugin may request is bounded by your subscription tier. These privilege levels are unrelated to subscription tier names — a plugin's privilege level says what it is allowed to do, not who published it or what you pay.
Every published plugin is cryptographically signed, and signatures are recorded in an append-only, tamper-evident transparency log so that publisher identity and version integrity are independently verifiable. You can confirm that the build you installed is the build that was signed, and that no version was swapped out after the fact.
What listing does and does not mean. We apply automated and manual checks before listing, including signature verification and policy screening. Those checks reduce risk. They are not a security audit and a listed plugin is not a plugin we vouch for — use of third-party plugins is at your own risk.
Account Security
- Passwords are stored only as salted, one-way hashes using a modern, computationally-hard algorithm. We never store, log, or transmit plaintext passwords.
- Multi-factor authentication is available and encouraged for every account.
- Session lock and account recovery follow a two-step, MFA-verified flow with short-lived, single-use unlock tokens.
- Device limits. Licence activation is bound to a limited number of devices per account to contain credential misuse. The number varies by subscription tier and is published with the tier details at https://alverium.net/pricing.
Web and Infrastructure
- Hardened web surface. Our web services ship a strict Content-Security-Policy, HTTPS everywhere with HSTS, and a defensive set of security response headers.
- Rate limiting and abuse controls protect public endpoints. IP addresses are used for security, abuse mitigation, and compliance screening, and are not used to build tracking profiles.
- Independent review. We engage third parties to review our cloud infrastructure and web services. That review covers our hosted services. It does not cover smart contracts, which are reviewed separately — see below.
Smart Contracts and On-Chain Components
Where Alverium ships on-chain components, they carry a different security model from our hosted services and are reviewed separately.
- Contracts are in scope for vulnerability disclosure — see below. If you find something in a contract, we want the report.
- Any external audit of a contract is reported per contract. Do not read a statement about our infrastructure review as covering contract code, and do not assume a contract has been externally audited unless we say so for that contract.
- Immutable code cannot be patched. Where a component is deployed without an upgrade path, a vulnerability found after deployment cannot be fixed in place. That property is deliberate — it is what makes certain guarantees meaningful — and it makes pre-deployment review and good-faith disclosure more important, not less.
Reporting a Vulnerability
We welcome reports from security researchers and will not pursue legal action against good-faith research that respects the guidelines below.
- Contact: security@alverium.net
- Scope: the Alverium desktop application, the marketplace, our public web services, our smart contracts, and the off-chain services that support them — including any key-management or re-keying component.
- Please do: give us a reasonable window to remediate before public disclosure, and provide enough detail to reproduce.
- Please do not: access or modify other users' data, degrade service for others, or run automated scans that generate disruptive load.
If you are unsure whether something is in scope, report it. We would much rather triage an out-of-scope report than have a researcher stay quiet about a finding in immutable code because they thought it was not covered.
We acknowledge reports promptly and will keep you updated as we investigate and ship a fix.
Contact
For security questions or disclosures:
Security Team Alverium, Inc. Email: security@alverium.net