Security
What bounds the key that collects your revenue
SolLoop runs a server holding a key that can pull tokens from your customers' wallets. That is the product, so this page is about what bounds that key.
What the collector key can and cannot do
The program's design bounds it tightly. Every collection is checked on-chain against the plan: the caller must be the owner or a listed puller, the amount must fit the remaining allowance for the period, and the receiving account's owner must be in the plan's destination list. That list is immutable from the moment the plan is published.
A stolen key can
- Submit collections for plans that list our collector as a puller
- For up to the plan amount, per period
- Only to the destinations written into the plan when it was published: your wallet, and the SolLoop treasury
It cannot
- Change plan terms or add a destination
- Move funds anywhere but those destinations
- Collect more than the cap, or from anyone who has not subscribed
- Collect from plans that do not list it
So the worst case is an attacker collecting subscriptions early, into your own wallet. Disruptive, and something we would detect as off-schedule collections. Not theft of customer funds.
Key custody
The collector key lives in the deployment platform's encrypted secret store, is loaded into memory once at boot, and is never written to disk, logged, or included in an error message by our code. The wallet holds only enough SOL for transaction fees. It signs nothing else.
Every plan lists two puller addresses, current and next, so rotating the key is a configuration change rather than asking every merchant to republish.
The treasury is a separate key
The fee destination in every plan is a multisig whose signers are people, not a server. Its address stays constant while its signers rotate, which matters because a plan's destinations cannot change after publication. The collector and the treasury are different addresses with different threat models.
What the widget shows your customer
The authorisation screen shows the destination address and the per-period cap read from the chain at that moment, never a cached copy. If the plan changed between the fetch and the signature, the program rejects the transaction rather than binding your customer to terms they did not see.
Audit status
The Solana Subscriptions program was built by Moonsong Labs and audited by Cantina. SolLoop's own services have not yet been independently audited; this page will say so when that changes.