Hot, hardware or multisig: choosing the wallets your business is paid to.

What is the difference between a hot, a hardware and a multisig wallet?

The three kinds differ in where the signing key lives and how many keys must agree before money leaves. A hot wallet is a wallet whose private key is stored, encrypted, on a device that is online: a browser extension or a phone app. A hardware wallet keeps the key on a separate device and asks you to confirm each signature on it. A multisig wallet is an account controlled by a program that moves funds only after a set number of its members approve.

Phantom's page on supported hardware wallets states the hardware case in one sentence: "Using a hardware wallet keeps your private keys offline while still allowing you to view assets, sign transactions, and interact with apps through Phantom." For multisig, the Squads documentation says of the confirmation threshold: "It represents the number of Squad members required to confirm before executing a transaction."

What does Fianto's receiving-wallet proof require from a wallet?

Fianto's receiving-wallet proof requires the wallet to sign a text message with the private key behind its own address, from a wallet running in your browser. During setup, under "The wallet you get paid to", you pick the wallet, Fianto sends it a message that starts "fianto wants you to confirm this wallet receives payments for your account.", and you sign. A signed message moves nothing and costs nothing; the difference from a transaction is covered in sign message vs sign transaction.

Five conditions decide whether a given wallet can pass:

1. It registers with the page through the Wallet Standard and offers the message-signing feature. A wallet without it gets "This wallet cannot sign messages. Choose another wallet."
2. The signature is an ed25519 signature checked directly against the address. A Solana address is the 32-byte public key itself, so Fianto looks nothing up: the key that owns the address has to sign.
3. You sign within 5 minutes; each request to sign works once.
4. The wallet does not already receive payments for another Fianto account.
5. Before your first sale it has a USDC token account, or creating a checkout fails with merchant_token_account_missing. Sending it any amount of USDC once creates one.

After approval the receiving wallet has very little to do. Customers sign their own payments, and subscription renewals are collected by Fianto without any signature from you, as how stablecoin subscriptions renew on Solana explains. You never pay a network fee on money coming in, so you never need SOL to receive. The wallet signs again only if you use the self-serve two-factor reset, which asks for its signature, and it needs SOL when you send money out of it. Changing or losing it is covered in securing the wallet you get paid to; the setup screens are in the docs on setting up your business.

When is a hot wallet enough to receive business payments?

A hot wallet is enough for receiving as long as it holds little and approves little. Receiving needs no signature from you at all, so the wallet's only exposure is the balance sitting in it and whatever you approve from that device. Both can be kept small.

Keep the receiving wallet for receiving: no trading sites, no airdrop claims, no connecting it to apps you are trying out. The signatures that empty hot wallets, and how to recognise them, are in wallet drainers and fake payment requests. Then move the balance out on a fixed schedule, so the amount at risk at any moment is a few days of revenue rather than all of it.

A hot wallet is the wrong place for the business's savings. Its key sits on a general-purpose device, and one approved malicious transaction can empty it.

Can a hardware wallet be your Fianto receiving wallet?

A hardware wallet can be your receiving wallet only if the browser wallet you pair it with can get it to sign Fianto's message, so test that before you commit. To use one with Solana apps in a browser you pair it with a software wallet, and each wallet vendor lists different devices as of 15 October 2026:

• Phantom lists Ledger Nano S, Nano S Plus, Stax and Flex for the extension by cable, and Nano X, Stax and Flex for the phone app over Bluetooth. It lists the Ledger Nano Gen5 and all Trezor and Tangem models as unsupported.
• Solflare says its extension can connect a Ledger or a Keystone.
• Backpack lists Ledger, Trezor and Keystone.

Signing a transaction and signing a message are different features, and Fianto's proof needs the second. Message signing is a known weak spot for Ledger accounts used through other wallets: Ledger's support centre has an article on Ledger Solana accounts in third-party wallets that cannot sign off-chain messages. Check its current status for your setup, then try the proof step with the device connected. If the signature cannot be made, you cannot finish the step with that wallet.

If it fails, nothing is lost. Use a software wallet (Phantom, Solflare and Backpack compared) as the receiving wallet and make the hardware wallet the savings destination: receiving into it needs no signature, only sending out of it does.

Can a Squads multisig receive Fianto payments directly?

Fianto has not verified that a Squads multisig vault can complete the receiving-wallet proof, so do not set one up expecting it to. Two pieces of documentation explain why we would not plan on it. Squads' settings page says: "The Squad Vault and Sub-accounts are PDAs derived from the multisig account address." And Solana's page on program derived addresses says: "Because the address is off-curve, no one can produce a cryptographic signature for it." Fianto's proof is exactly such a signature, checked against the address. Members of a Squad approve proposals with their own keys, which is not the same as the vault address signing a message.

Where a Squads vault fits is one step later, as the place the receiving wallet sweeps to. Squads gives three rules that matter for a business treasury:

• On the threshold: "Avoid setting it at 1/n signatures, as this creates a single point of failure." And at the other end: "Avoid setting it at maximum capacity (e.g., 2/2, 3/3) to prevent potential loss of access." Two of three members satisfies both rules.
• Send funds to the vault address, never to the multisig account address. The same page warns: "Sending assets or setting authority to the Multisig Account address will cause irreversible loss of funds/assets."
• The Settings tab lets a Squad add spending limits and a time lock, so a withdrawal can be capped or delayed before it executes.

How should a small business split receiving and savings wallets?

Choose the savings side by how many people must agree before money leaves the business, and keep the receiving side the same in every case:

Then set it up in this order:

1. Create the receiving wallet fresh in a browser wallet that can sign messages, and write its recovery phrase down offline.
2. Prove it in Fianto setup, then send it a small amount of USDC so its USDC token account exists before the first sale.
3. Create the savings wallet or Squad. For a Squad, copy the vault address from its Settings tab, not the multisig account address.
4. Save the savings address in your wallet once and send a small test amount before the first real sweep. Never pick it from your transaction history later: address poisoning on Solana explains why.
5. Keep a little SOL in the receiving wallet for sweeps and any refunds you send. Each transaction you send pays a base fee of 5,000 lamports per signature, plus any priority fee your wallet adds.
6. Sweep on a fixed day, not when you remember. A calendar entry is enough.