v1.37.0, shipped on 2026-04-06, adds a feature that sounds smaller than it is: single-key Schnorr signing for Enterprise vaults. Where the default vault path collects two signatures from two devices, a 1-of-1 vault now spends with one direct Schnorr signature from one configured key. The headline is policy, not protocol — Enterprise teams can decide, per vault, which risk profile a given pot of money deserves. The same release brings Enterprise FluxNode start support, an EVM gas-fee math fix, tighter number precision in formatting and CSV export, and steadier SSP Connect socket plumbing.
1-of-1 vault signing arrives
The new mode is called 1-of-1 — labelled wallet_only or key_only inside the vault configuration depending on which key the organization designates as the spender. A vault set this way needs exactly one signature from exactly one key to authorize a transaction. No co-signer prompt, no second device handshake, no round-trip through the multisig flow. The user reviews the transaction in the same vault-aware UI introduced in SSP Enterprise launches: multisig vaults for businesses, confirms on the chosen device, and the wallet broadcasts.
What this unlocks, in practice, is a faster path for the kinds of spend that don't justify a two-device ceremony every time: paying a small invoice, topping up an operations float, settling a recurring API bill, moving funds inside an org-controlled set of addresses. The work that used to require two humans aligned at two devices for sub-tenner outlays becomes one tap on one configured key.
Multisig isn't gone — it's a policy choice now
It's important to read the change correctly. SSP did not weaken multisig and did not flip a default. The 2-of-2 architecture that has secured the wallet since Introducing SSP Wallet — true 2-of-2 multisig goes live remains the default and remains the right answer for high-value vaults. What v1.37.0 adds is the option, scoped to Enterprise, to lower the threshold on a specific vault when the organization decides that vault doesn't need two-of-two protection.
The framing matters because risk is not uniform inside a treasury. The vault holding the corporate reserve and the vault holding twenty dollars of hot-wallet float should not be governed by the same friction. Until v1.37.0, they were. Now they aren't, and the choice sits with the people who actually know the risk: the org administering its own keys.
Direct Schnorr signatures
Under the hood, 1-of-1 mode uses the same Schnorr primitive SSP brought to the EVM side in Ethereum joins SSP — Schnorr multisig on ERC-4337 — only now the signature is produced by a single key instead of being a Schnorr-aggregated 2-of-2 over ERC-4337. The transaction looks normal on-chain. There is no special opcode to parse, no multisig contract handshake to wait for. Where the 2-of-2 path aggregates two partial signatures into one Schnorr signature and submits it, the 1-of-1 path produces that same kind of signature directly from one key.
The implication for verification is clean: external indexers, block explorers and counterparties don't have to know which mode a vault is using. They see a valid Schnorr signature, the chain accepts it, and the funds move. The policy difference lives where it should — inside the wallet's authorization logic, not on the wire.
Enterprise FluxNode start
The other Enterprise-shaped change in v1.37.0 is operational. Enterprise vaults can now start Flux nodes directly from the vault — sign the collateral transaction and the delegate configuration in the same flow you already use to sign payments. For organizations running Flux infrastructure, that closes a gap: collateral that lives in a vault no longer has to be re-routed through a personal wallet to be staked.
Combined with the Flux delegates and "start all nodes" features from Flux delegates and node management arrive in SSP, Enterprise operators now have an end-to-end node lifecycle inside the wallet — collateral signed from the vault, delegate configured from the vault, fleet managed from the wallet.
EVM gas math + CSV precision
Two quieter fixes round out the release. The EVM gas-fee estimator had been double-counting maxPriorityFeePerGas — adding it on top of maxFeePerGas even though maxFeePerGas already includes the priority fee. v1.37.0 removes the duplicate, so the estimate you see on screen matches what the wallet actually pays. Affected chains stop over-quoting; receipts line up with previews.
Number formatting also tightened up. Crypto and fiat values, and the CSV export introduced in More ETH tokens, CSV export and Brave support, now go through toFixed() plus parseFloat() instead of raw toNumber(). Floating-point dust that occasionally crept into precise balances goes away. Underneath, SSP Connect's socket context got steadier message handling — fewer dropped events when a dApp tab is busy.
None of these change the policy story, but together they keep the new flexibility from being noisy.