Those are fair points, I get the concern and the trade-offs you’re pointing out.

A bit of context:

• The SaaS isn’t aimed at privacy-maximal users. For the Stacker News crowd, I’d imagine self-hosting is the right choice.
• Stripe was simply the fastest way to get the hosted version off the ground. Now that https://docs.btcpayserver.org/Subscriptions/, that’s something I’m planning to add.
• Even in the SaaS, Canary only handles watch-only data. No keys, no signing, no spending, which keeps the risk surface much smaller than wallets or custodians.

As for who the SaaS might be for:

• People who want movement alerts but don’t want to run a node and are comfortable with the trade-offs.
• Companies, funds, or orgs holding BTC, where the privacy model is different than on a personal level (treasury monitoring, controls, alerts).

Is a hosted service a potential honeypot? Yes, like any hosted Bitcoin service. That’s exactly why a self-hosted option exists, where no data is shared with third parties. It’s built on BDK, and the data is fetched from your own instance of Electrum server, and notifications is sent to ntfy (which also can be self-hosted).

Why does the project need a stripe integration?

Thanks, that’s a good question!

Short answer: it doesn’t, unless you use the SaaS version.

Canary is split in two (same codebase):

• Self-hosted version: open-source, runs on your own node, no Stripe, no accounts, no payments.
• Hosted SaaS (canarybitcoin.com): for people without a node, and Stripe is only used here for billing.