Hey Firo Folks,
I’m looking for long term security for holding Firo. So I was wondering what current hardware wallets are supported by Firo? I tried to find documentation on this on the firo site but couldn’t find anything really.
Are HW wallets like Trezor or Keystone supported?
Just so you know I’m trying to avoid Ledger
Thanks
3 Likes
anwar
November 7, 2025, 3:18pm
2
Currently Ledger and Trezor, interfacing through Electrum Firo.
Ok thanks for answering that. When it comes down to Trezor, can you tell me which models work currently with Electrum?
Another thing also, I also had two other questions somewhat related. So I checked Electrum and it looks like it doesn’t support spark addresses? Is spark address support planned for Electrum on the Firo roadmap anywhere?
After watching a yt video on Firo I was under the impression or assumed “view keys” have been implemented but I think that is only for the Core wallet?
Forgive me if I’m mixing things up here I might be thinking of watch only wallet of the likes. I’m kinda a crypto newbster but something along the lines of setting up Firo with a hardware wallet on airgapped computer. Then writing down or exporting the view key onto another system like phone or PC so I can view incoming funds would be ideal for me and maybe others.
1 Like
F*** man why does the WEF have their hands in everything. First ProtonMail now Ledger!
Was always leery of Ledger due to it not being “opensource” and past security breaches I read about. Then add Cloudflare in the mix which most of the internet and crypto nodes use as DNS really paints the picture of the WEF’s plans to control the internet and transactions IMHO. If this tinfoil take bothers anyone just gloss over it as another schizo rambling in cyberspace.
1 Like
The only thing I see when it comes to view keys is this:
opened 02:06PM - 27 Sep 23 UTC
The following Issue and its individual points refer mostly to section **6 View K… eys and Payment Proves** of the paper [“Lelantus Spark: Secure and Flexible Private Transactions”](https://eprint.iacr.org/2021/1173) . It seems that the implementation is not complete and/or not documented enough. Apologies for the parts which are indeed implemented and not found by me.
#### Let’s maybe dissect the parts along a user story.
Alice has a charity organization and sells for the good cause paintings in her. She decides for Firo to receive anonymous donations and also so that painting buyers can shop without revealing to her their full wealth. Further Alice has chosen Firo Spark, as it comes with the incoming view key and the full view key.
She wants to make public the donation amounts she received for her charity with the incoming view key as it
> “is used in Identify operations to determine when a coin is directed to an associated public address, and to determine the coin’s value and associated memo data. This permits two use cases of note. In one case, blockchain scanning can be delegated to a device or service without delegating spend authority for identified coins. In another case, wallet software in possession of a spend key can keep this key encrypted or otherwise securely stored during scanning operations, reducing key exposure risks.”
The full view key she wants to pass to her accountant Bob.
Quick look into `sparkwallet.cpp` to find:
```
// Generating spark key set first time
spark::SpendKey spendKey = generateSpendKey(params);
fullViewKey = generateFullViewKey(spendKey);
viewKey = generateIncomingViewKey(fullViewKey);
```
Alice is set up, shares her donation address, and can do her transactions (receive / spend spark). Now she wants to publish her donation address as well as the viewKey so that other can transparently see the amount she collected. She looks into QT and can’t find anywhere the possibility to reveal the viewKey also the cli doesn’t offer a possibility to get the `viewKey `out…
- `DumpViewKey `function missing
- GUI `viewKey `in/output not possible
Alice breaks open the code a bit to get her viewKey out and publishes it with her donation address. Eve, who is interested in the charity of Alice sees the address and the view key and is curious to see how much she collected. She takes the published information and finds out… There is no possibility to import the viewkey nor is it possible to pass it as parameter to a CLI function to get the balance or history of the account.
- `ViewIncoming “Account/Address” “ViewKey”` missing.
- `getBalnceOf “Account/Address” “ViewKey”` missing.
Well, viewKey is one thing. Now that the tax season approaches Alice passes to the fullViewKey, that she cracked out earlier, to her accountant Bob. She informs him that there is no need to get a full QT-GUI setup as there is not possibility to import the fullViewKey there for the time being. Alice argues, the
> “full view key is used in Recover operations to additionally compute the serial number and tag for coins directed to an associated public address. These tags can be used to identify a transaction spending the coin. Providing this key to a third party permits identification of incoming transactions and detection of outgoing transactions, which additionally provides balance computation, without delegating spend authority. Users like public charities may wish to permit public oversight of funds with this functionality. Other users may wish to provide the functionality to an auditor or accountant for bookkeeping purposes. In the case where an address is used in threshold multisignature operations, a cosigner may wish to know if or when another cohort of cosigners has produced a transaction spending funds.”
Further the paper says that
> “Address owners can securely provide third parties with opt-in visibility into incoming transactions or all transactions associated to the address; this functionality allows for offloading chain scanning and balance computation without delegating spend authority.”
So Bob is confident that with a fullViewKey he will be able to send CLI calls to public nodes and get all the data required to perform the tasks Alice expects. Well, Bob has a hard time and it seems that there is no RPC function he can pass the fullViewKey to, to get his job done. Besides the missing function he notices that most wallet related RPC function require an authentication. So even if there were a function, if he doesn’t have the RPC-authentication of the public node he can’t perform the task without tunning a full node himself.
- `DumpFullViewKey` function missing
- GUI `fullViewKey` output not possible
- `getBalnceOf “Account/Address” “FullViewKey”` missing.
- `GetSparkAllSparkAdresses “Account” “FullViewKey”` missing.
- `GetSparkAllUsedSparkAdresses “Account” “FullViewKey”` missing.
[Next part not described in Section 6 just thinking further – feature request(?)]
Bob and Alice came along with a solution outside the Network. Now Bob wants to invoice Alice for his service and prepares a transaction passes it offline to Alice for signature, as only she has the signing authority. Bob gets the signed transaction offline back from Alice. As he has no full node running, but he can’t find a call functions with public nodes where he could submit the signed transaction to a public node and broadcast it to the network….
#### Summary
Center pieces of Lelantus Spark are implemented! 😊 However, it seems that core elements of the paper from section 6 have not undergone development and so spark is not complete on this end. There are no indications known to me, that spark would come in multiple waves where the missing parts are factored in later. Whether the transaction signing and verification by the view key of such tx is working properly has not been tested from my end yet, due to possible missing implementation/documentation/functionality stated above. From my understanding the view keys are on account level, not on address level (I might be wrong here). An extraction function of the account and the corresponding viewKeys would be highly appreciated.
In my humble opinion, all the functions (besides the Dump/retrieve functions) should be implemented in a way that they can be queried from every node in the network without RPC-authentication at the public nodes end in order to provide for more light wallet use cases without full node running.
2 Likes
Azz
November 24, 2025, 12:47am
6
Does this include all ledger models? Tried with a flex couldn’t get anything
Good wiki and read on Hardware Wallets here:
1 Like
pepe
June 18, 2026, 6:31am
9
Ledger Flex works for now.
Any plans to add support for other hardware wallets?
for the blatantly obvious reasons.