On 2025-10-23, SSP Wallet v1.27.0 landed with the deepest runtime security change of the year: LavaMoat, the JavaScript compartmentalization framework pioneered by MetaMask, is now integrated into SSP. Each third-party dependency the wallet loads is sealed inside its own sandbox, so a compromised package — the npm supply-chain risk every modern wallet faces — can no longer read or alter what other parts of the wallet are doing. The release also tightens the Content Security Policy, hides a security-test page behind an easter-egg gesture, and brings a handful of UI polish wins.
Runtime sandboxing arrives in SSP
LavaMoat is, in 30 seconds: a runtime that takes the dependency tree of a JavaScript app, isolates every package into its own compartment, and only lets each compartment touch the globals and APIs it has been explicitly granted in a policy file. By default a third-party dependency cannot read localStorage, cannot call fetch, cannot reach into the keyring, cannot monkey-patch Object.prototype. If it tries, the runtime stops it.
That is a different posture from the one most web apps have, where every imported package runs with the same authority as the app itself. Inside SSP, the code that handles private keys, the swap integration that talks to exchange APIs, and the third-party UI helpers used to share a single global scope. As of v1.27.0, they don't.
Why compartmentalization matters
The threat compartmentalization is designed to neutralize is the npm supply-chain attack. The pattern has been seen in the wild repeatedly: an attacker takes over a popular package, ships a malicious version, and rides the transitive-dependency wave into every app that imports it. For a wallet, the impact of a malicious package running with full app authority is catastrophic — it can read seed material in memory, exfiltrate private keys, or rewrite transaction destinations before the user signs.
LavaMoat doesn't prevent the attack from reaching the app. It removes the impact. A compromised dependency, even one buried five levels deep in the tree, runs inside a compartment that has no access to the wallet's signing surface, no access to network egress beyond what the policy permits, and no way to read state from another compartment. Compromised package ≠ compromised wallet — the equivalence holds for the first time in v1.27.0.
This complements rather than replaces the protections that landed earlier in the year. SSP's source code was already verified by the full Halborn audit, and the binary you install was already provable against that source through deterministic builds and GPG signing. LavaMoat closes the runtime gap: even if a dependency goes rogue after the build is signed, it can't escalate to wallet-level access.
Stronger Content Security Policy
Alongside the runtime sandboxing, v1.27.0 also tightens the Content Security Policy at the browser layer. CSP is the budget that the wallet declares for itself — which origins it is allowed to load scripts from, which origins it is allowed to talk to, which inline behaviours are permitted. A stricter CSP shrinks the space an attacker has to operate in even before LavaMoat enforces its policy inside the page.
The combined effect is two layers of containment: the browser refuses to load resources outside the declared policy, and any JavaScript that does run is then compartmentalized by LavaMoat. Each layer covers a different failure mode, which is the whole point of defense in depth.
A hidden security test page
For internal verification — and this is the only feature in the release that ships with a deliberate easter egg — v1.27.0 includes a security test page that is not exposed in normal navigation. Clicking the version number in the app several times in quick succession reveals it. The page runs a battery of checks against the LavaMoat policy and the CSP rules, so reviewers and red-teamers can confirm the protections are active in the build they're inspecting without having to instrument the wallet themselves. It is not intended for everyday users, and there is nothing exploitable behind it; it's simply a more convenient way to verify what v1.27.0 promises.
Defense in depth: audited + reproducible + sandboxed
The interesting part of v1.27.0 is not LavaMoat in isolation; it is how the three pieces compose. Audited source (Halborn), reproducible binary anyone can verify against that source (deterministic builds), and a runtime that contains any single compromised dependency. Together they change the question from "do I trust SSP's full dependency tree?" to "do I trust the audited core?" — a much smaller and more answerable trust surface.
UI polish lands on top: swap exchange logos now render correctly, and the brand palette has been brought into alignment. The compartmentalization is what changes how the wallet survives.