Flux in SSP: Sending, Holding, and the One-Hour Rule
Most chains in SSP behave the way you would expect from having used any other wallet. Flux mostly does too — and then it does one thing no other chain in SSP does, which is worth understanding before it surprises you.
Flux transactions expire.
What Flux actually is
Flux is a decentralised infrastructure network. Its participants run nodes that provide computing power — the machines that host applications, serve APIs and back other projects' infrastructure — and are paid in FLUX for doing so. The token is not the product; the compute is. The token is how the network pays for it and how operators post a stake worth losing.
That matters for how you should think about holding it. FLUX is an infrastructure token whose demand is tied to actual usage of a compute network, which is a very different thing from a store-of-value asset like Bitcoin or a smart-contract platform's gas token. The Flux project's own site is the right place for the network side of the story; this guide is about the wallet side.
One piece of context worth stating plainly, because it is easy to miss and we would rather say it than have you find out elsewhere: SSP is built by the team behind Flux. That is why FLUX support in SSP runs deeper than a listing — node management included — and it is also why you should weight our enthusiasm for the network accordingly and do your own reading.
How SSP handles Flux under the hood
Flux is a UTXO chain in the Bitcoin lineage, but it descends specifically from Zcash, and it carries that inheritance in visible ways.
Multisig lives in a P2SH address. Where SSP's Bitcoin addresses use native segwit, Flux 2-of-2 addresses are pay-to-script-hash — the older format, starting with a t. Nothing about the security is different; the two-of-two arrangement is the same one SSP uses everywhere. It just means Flux addresses look different from your Bitcoin ones, and slightly more of each transaction is script.
The signing prefix still says Zelcash. If you ever inspect a signed message closely, you will see the network's original name. Flux was ZelCash before it was rebranded, and the message prefix is consensus-relevant — changing it would break every signature verifier in the ecosystem. So it stays. A small piece of archaeology, not a bug.
Transactions use version 4 with a Sapling-style group ID. Again inherited from Zcash. It is invisible to you, but it is the same lineage that gives Flux the one feature this article is really about.
The one-hour rule
A Flux transaction is built with an expiry height: the block number after which the network will no longer accept it. SSP sets that window to 30 blocks past the current tip, and at roughly two minutes a block that comes out near an hour.
For a single-signature wallet this is invisible. You build and broadcast in the same breath, and thirty blocks is an eternity.
For a two-device wallet it is worth knowing about, because there are two signatures and a human between them. You approve on the browser extension, then you pick up your phone — and if your phone is in another room, on a charger, out of battery, or you get pulled into a meeting between the two steps, the clock is running.
The good news is that the failure is completely benign. An expired transaction is one the network never accepted, which means it was never mined, which means no fee was paid and no coins moved. Nothing is stuck, nothing is lost, and nothing needs unwinding. You build the payment again and sign it again, this time with both devices to hand.
That is the entire practical implication: for Flux, and only for Flux, start the transaction when you are ready to finish it. It is the same discipline critical actions ask for elsewhere in SSP — except here it is enforced by consensus rather than by good habits.
Fees, and the absence of an undo
Flux fees are simple in a way Bitcoin's no longer are. SSP uses one satoshi per byte, the network minimum, and that is genuinely enough — Flux blocks are not congested, and there is no fee market to bid into. A typical 2-of-2 payment costs a fraction of a cent.
Two guard rails sit around that. The dust limit is 546 satoshis, so outputs smaller than that cannot be created at all. And SSP caps the fee it will ever attach to a Flux transaction at 10 FLUX, which exists purely to make a catastrophic fee bug impossible rather than because any real transaction approaches it.
The more consequential fact: Flux does not support replace-by-fee. On Bitcoin, a transaction that is stuck at too low a fee can be re-broadcast at a higher one. On Flux there is no such mechanism — a transaction is either accepted as it is or it expires. In practice this is a non-issue, because the fee is not a variable you are tuning and there is no congestion to get stuck behind. But it is why the expiry window is a feature rather than a hazard: instead of transactions lingering in mempools indefinitely, they simply cease to exist.
If you find yourself with a wallet full of small Flux outputs from mining or node rewards, the general UTXO advice applies — consolidating them when fees are trivial keeps future transactions small.
Running FluxNodes from your wallet
This is the part of Flux support that has no equivalent for any other chain in SSP.
FluxNode operators must lock collateral: a specific amount of FLUX held at an address, proving they have something to lose. SSP recognises the three tiers by their collateral size — Cumulus at the entry level, Nimbus at 12,500 FLUX, and Stratus at 40,000 FLUX — and shows nodes backed by your addresses in a dedicated Nodes view.
The design point worth appreciating is where the collateral sits. It stays in your 2-of-2 multisig address. Running a node does not mean sending coins to a staking contract, a custodian, or a separate hot wallet. The collateral is proven by an unspent output you control, and moving it still takes both of your devices — exactly like any other Flux balance.
Node operation itself needs a second kind of key, an identity keypair that signs node management messages. SSP derives that deterministically from the same seed, at its own dedicated branch of the derivation tree, so there is nothing extra to back up: the words that restore your wallet restore your node identity with it.
Where Flux fits in a portfolio
Some honesty is more useful here than enthusiasm.
FLUX is a small-cap infrastructure token. Its price behaviour is far more volatile than Bitcoin's, its demand is tied to a specific network's adoption rather than to a broad macro thesis, and the node tiers above the entry level represent serious capital commitments. None of that is a reason not to hold it. All of it is a reason to size the position as what it is — a bet on one network's execution — rather than as a savings balance.
What self-custody changes is not the asset's risk but the counterparty's. Holding FLUX in a 2-of-2 vault means the network's fortunes are the only thing you are exposed to, rather than the network's fortunes plus whatever an exchange does with your balance in the meantime. What actually stops a transaction covers why that distinction is the whole point.
Getting started
Flux appears in SSP's chain switcher alongside every other supported network, with the same key material and the same two-device signing. There is no separate setup, no bridging, and no wrapped version to worry about — you are holding the native asset on its own chain.
The practical checklist is short. Keep both devices to hand before you start a payment. Expect Flux addresses to look different from your Bitcoin ones. Don't worry about fees. And if you are running nodes, know that the collateral never leaves the address you control.
For the click-by-click walkthrough of a payment, the step-by-step guide to sending Flux with SSP picks up where this one leaves off.
