No. This is a community‑packaged distribution referencing upstream code. It targets users who are comfortable verifying provenance, hashes, signatures and build steps. There is no support obligation or warranty.

Compute the SHA‑256 of the artifact, compare with the hash published in the upstream release, and validate code signing if available. Prefer testing in a disposable VM first; never import primary seeds until you fully trust the build.

• Windows: Get-FileHash .\file.exe -Algorithm SHA256 + Get-AuthenticodeSignature
• macOS: shasum -a 256 file.dmg + codesign -dv + spctl -a -vv
• Linux: shasum -a 256 file.AppImage

Many wallets share BIP39 and Solana derivation but differ in account discovery and derivation paths. Always test with a disposable seed to confirm addresses and balances with an independent explorer first.

Depends on wallet adapters supported by that dApp. Some projects prefer newer stacks. Start with tiny amounts, read transaction prompts carefully, and confirm on‑chain state before scaling up.

Use reputable HTTPS endpoints or self‑hosted nodes. Assume RPC providers can see metadata about submitted transactions. Consider endpoint rotation, separate keys for separate contexts, and watch‑only views for balance checks.

Yes. Clone upstream, lock dependencies, build inside a clean VM/container, and compare output hashes to published artifacts for reproducibility where possible.

1. Clone repo and pin a commit.
2. Lock dependencies.
3. Build in a clean environment and compare artifacts.

Start with a fresh disposable seed. Use tiny amounts; verify quotes, slippage and fees; then confirm resulting token balances via a trusted Solana explorer.

A correct hash confirms integrity, not intent. Review the certificate chain if signed; inspect the binary using local tools; and, if satisfied, create a local exception in your AV rather than disabling protection globally.

Sollet is Solana‑native. You may configure RPC endpoints and switch between public endpoints or self‑hosted nodes where appropriate (mainnet, testnet, devnet).

• Separate hot and cold keys for different risk profiles.
• Use allowlists where possible.
• Keep test balances to validate flows before using main funds.
• Prefer watch‑only views when inspecting balances from untrusted networks.

Open an issue in the upstream repository with OS version, reproduction steps and the specific commit/release. For site issues, contact support@sollet-wallet.net.

For strict offline signing you may need a wallet purpose‑built for air‑gapped flows. Review Sollet’s capabilities and consider combining with hardware wallets where applicable.

Close the app, clear its local cache/config directory, relaunch and re‑add watch‑only or test accounts. Never clear data without a confirmed backup of your seed.

We aim to minimize collection. See the Privacy Policy for details on logs, optional analytics and retention. You can browse content without providing personal data.

No. Use at your own risk. Read the Terms of Use for disclaimers and limitations of liability.

• Standalone Download page
• Home → Resources
• Sitemap