Fetch the release.
The bootstrap downloads qos-source.tar.gz and its published SHA-256 file from the latest GitHub Release, rejects unsafe archive contents, and installs a private source copy.
Install the security boundary first
Your agent can trade. It does not get the keys.
Install qOS Labs, walk through one guided setup, and give an AI agent a revocable policy instead of a wallet secret.
One-command setup
Choose your system.
Network
Ubuntu 20.04, 22.04, or 24.04 · direct install
curl --proto '=https' --tlsv1.2 -fsSL https://qoslabs/install.sh | sh
Mainnet is the default. The wizard first asks whether to use your existing external key or generate a local key with the explicit --insecure warning.
What the installer does
From zero to a constrained agent shell.
The host wrapper creates the supported Ubuntu environment when necessary. Inside it, qOS Labs Labs verifies the latest GitHub Release checksum before any release code runs.
Choose your key setup.
Use a key you already control through a reviewed signer adapter, or let qOS Labs Labs generate one through the warned --insecure path. Devnet runs only when explicitly selected.
Connect the agent.
qOS Labs can issue a scoped, revocable agent credential, generate its skill pack, start the loopback API/MCP listener, and open the operator shell.
LinuxRuns directly on supported Ubuntu releases.
macOSUses Homebrew + Lima to create a mount-isolated Ubuntu 24.04 VM.
WindowsUses WSL 2 + Ubuntu 24.04; Windows may request one administrator approval and restart.
Running a remote script is a trust decision. Read all three installer scripts first ↗ and pin the documented release digest when your threat model requires independent verification.
The short version
Your bot can make decisions. It shouldn’t hold the keys.
Normal trading setups trust a full operating system, app dependencies, wallet files, RPC providers, and any code that can reach a signing function. One bad layer can become a very expensive problem.
qOS Labs moves the final say into firmware. The app proposes a typed trade. A separate signer checks the program, accounts, mint, amount, slippage, fees, timing, and exposure. If the request breaks policy, it does not get signed.
Why it exists
Assume the trading app gets compromised.
qOS Labs is designed so a compromised app still cannot read the key or sign whatever it wants.
Secrets stay local.
Keys, strategies, positions, firmware secrets, and live order flow stay offchain. Public assurance does not require publishing private machine state.
The machine can prove what it booted.
Firmware measurements and policy versions can be attested or anchored onchain without exposing the sensitive work happening inside the machine.
How it works
Four checks between an idea and a signature.
Verified boot
Every mutable boot stage is checked before the machine runs it.
Isolated signing
The trading app asks for a trade. It never gets the private key.
Hard policy
Unknown programs, bad accounts, stale requests, and excess risk get rejected.
Private routing
Signed transactions can travel through configured direct or private paths.
The signer says “no” to
Requests that don’t look exactly right.
- ×Arbitrary sign(bytes) requests
- ×Unknown Solana programs
- ×Unapproved mints or accounts
- ×Trades above exposure limits
- ×Excessive slippage, tips, or fees
- ×Stale or replayed requests
SOL / 01
Starting with Solana
A hard test for safer automated signing.
Solana combines fast execution, composable programs, and latency-sensitive trading. qOS Labs Labs uses post-quantum cryptography for boot, updates, recovery, and management while keeping an isolated Ed25519 signer for Solana-compatible transactions.
Research status
Early-stage. Real code. Not production-ready.
Use Devnet. Keep mainnet funds away.
The repository includes a working Devnet-only Solana sandbox and a deliberately incomplete firmware starter. Production deployment still requires platform implementations, hardware isolation, independent review, and extensive fault testing.
The concept is being discussed with AMD. This does not announce a partnership, endorsement, product commitment, or integration.
Firmware should be the root of trust—not another thing you hope is secure.