A security tool that only lists its strengths is telling you half of it. These are the failure modes of a software air gap, written by the people who built one. Every criticism on this page is one we would rather state ourselves than have you discover.
The root key is an AES-256-GCM ciphertext on a drive you hold. It is decrypted into memory-locked RAM on a machine with no network path, for as long as it takes to sign, then wiped. Online, an agent holds a disposable session key bounded by a policy the root signed, and every transaction it proposes is decoded and checked before a signature exists.
That removes one specific class of loss: the remote attacker. Malware on your everyday machine, a compromised dependency, a hijacked browser extension, a prompt-injected agent. None can reach a key that is not on a networked machine, and none can push the online session key past its policy.
There is no certified chip. A hardware wallet's secure element resists an attacker who has the device and the skill to attack the silicon. Coldstar has nothing equivalent. If physical theft by a well-resourced attacker is your threat, buy a certified device. We say which one on our comparison pages.
If the machine that decrypts the key is already compromised, this design fails completely. It captures your passphrase, and the drive is right there. The air gap defends the online side and assumes the offline side is clean. That assumption does real work.
Anyone holding the session secret does not need Coldstar at all; they can sign with web3.js directly. No local policy, revocation, or ledger reaches them. Policy bounds the agent, not a thief with the key file. For that, funds need on-chain enforcement such as Squads spending limits.
This decrypts private keys and has not been audited. An independent audit is planned before the production release. Until then you are trusting review you have done or have not done. The code is MIT and small on purpose; the policy evaluator is a pure function and the decoder has no I/O, and those are where a bug becomes a loss.
Allowlisting a program means accepting what it does internally. A swap cannot be statically bounded; simulation measures the real debit and tightens this without removing it. Keep the list short.
The most likely failure is not cryptographic. It is someone running the offline step on a laptop with Wi-Fi merely switched off. See below.
Switching Wi-Fi off in software is not an air gap. Neither is a machine you also browse on, nor a virtual machine on a networked host, nor "I disconnected it for this bit".
So the cold-side tool checks. coldstar-sign-policy refuses to read the root key when the machine has a live network interface, names what it found, and requires an explicit override to continue.
coldstar-sign-policy: THIS MACHINE HAS A LIVE NETWORK PATH: en0 10.0.0.42 and 31 more Refusing to read the root key on a networked machine.
That check is a guard rail, not proof. No interfaces does not prove isolation: a virtual machine on a networked host, a tether attached a minute later, Thunderbolt networking, or a radio the operating system does not enumerate would all pass it. Claiming more would repeat exactly the mistake the check exists to catch.
The built output is committed so the package installs straight from source control, and continuous integration fails if it does not match the source. Releases publish from that pipeline with npm provenance, so the tarball on the registry is attested to the workflow run and the commit that produced it. None of that makes the code correct. It makes "the code you can read is the code you installed" checkable rather than something you take on faith.
No. The key is protected at rest by AES-256-GCM and a passphrase, and in use by the fact that the machine decrypting it has no network path. Against physical theft by a well-resourced attacker, a certified device is better, and our comparison pages say so.
The design fails completely. That is why a dedicated machine, ideally a read-only live image, is not optional advice.
No. Beta, pre-audit, and it decrypts private keys. An independent audit is planned before the production release.
Because you would find them anyway, and because a list of failure modes written by the vendor is the only kind you can check against the code. The alternative is discovering them from someone else, later, with funds at stake.
Last reviewed 2026-09-06. If something here is wrong or incomplete, tell us and we will fix it.