Search for a passive income SDK and you will find a dozen products making a nearly identical claim: your users opt in, some unused bandwidth gets relayed, you get paid monthly per user, nothing changes in your app.
The claim is broadly true of all of them. It is also not the useful part, because the thing that decides whether you regret integrating one is never the pitch — it is what the SDK does on a user's device at 2am on a metered connection, and what your support inbox looks like a month later.
We build one of these. That is a reason to discount our opinion about which is best, and a reason to trust the list of questions, because we have had to answer all of them.
Who is actually in this category
The developer-facing bandwidth-sharing SDKs you are likely to encounter include Bright SDK, Infatica's SDK, Pawns.app, Honeygain and Cash Raven. There are others, and the list changes.
We are not going to publish a comparison table of their rates and limits. Any such table is out of date within a quarter, and a vendor writing one about its competitors is not a source you should trust anyway. What we can give you is the set of questions that actually discriminates between them, which you can put to any vendor including us.
If a vendor will not answer one of these in writing before you integrate, you have learned the thing you needed to learn.
1. Which limits can you, the developer, change?
The correct answer is none.
If an SDK lets you raise its bandwidth ceiling or loosen its data cap, then those limits are a suggestion, and whatever the SDK does on your user's phone is now your liability rather than the vendor's. A configurable cap also means the cap lives in configuration, which means it can be changed remotely without a build.
Ask specifically: is the limit enforced in the compiled binary, or read from a config the server can push? Those are very different answers.
2. What happens when the device is under sustained load?
"Opts out entirely" is a better answer than "throttles."
Throttling means the SDK stays resident and keeps competing for resources on a device that is already struggling. Opting out means it stops, and checks back later.
This matters most on the low-end Android hardware where a large share of your users actually live, and it is the difference between a support ticket that says "the app got slow" and one that does not exist.
3. Is it honest about being continuous?
Be suspicious of "only runs when the device is idle."
Deciding what "idle" means on a phone is a genuinely hard problem — screen off is not idle, charging is not idle, and a background sync is not idle — and most implementations solve it by not really solving it. A vendor claiming "idle-only" operation is either doing something sophisticated they can describe, or describing something they do not do.
The defensible design is the other one: run continuously inside hard limits as a background task that yields to the app it lives in, and opt out entirely when a limit is hit. Ask which one you are being sold.
4. Can you see the consent screen before you integrate?
If not, that is your answer.
The consent screen is the single most important piece of the integration, because it is the thing your users will see and the thing a store reviewer will judge. You should be able to read the exact wording, see the flow, and know whether it can be restyled to match your app before you write any code.
Then check the harder version of the question: can the SDK transmit anything before consent is granted? The right architecture makes that impossible rather than merely discouraged — not a settings toggle defaulted on, not a clause inside a licence agreement nobody reads.
5. Who buys the traffic, and what is blocked?
Vagueness here is the whole risk of the category.
You want a specific description of the demand side — ours is public web data collection: price and availability monitoring, flight and hotel search, SEO and ad verification, market research, and AI training data — and a specific blocklist. Ours permanently blocks .gov and .edu, banks and financial institutions, card processors, login endpoints, sensitive APIs, any reported-abuse domain, and the user's own local network.
If a vendor cannot tell you what is blocked, they are telling you nothing is.
6. How is a paid user actually defined?
This is where the money quietly differs, and it is almost never on the pricing page.
"$0.50 per user per month" can mean several different things depending on what counts as a user and when. Ask:
- Is there a minimum daily activity bar, and what is it?
- Does a partial month pay a partial amount, or does it round somewhere?
- Is the figure per user, per active user, or per device?
- Which devices are excluded, and how many of yours will that be?
For us: a user counts for a day once their device has been sharing for 60 minutes in that UTC day. Each qualifying day is worth the monthly rate divided by the days in the month, and the month is the sum of its days. A device that shares for 59 minutes on a Tuesday earns nothing for that Tuesday. Devices on hosting, datacenter or VPN IPs are not counted.
We wrote the whole arithmetic out partly because a previous version of that page described it differently and we would rather publish the correction than quietly fix it.
7. What does it cost you in crashes, size and store risk?
Three separate numbers, and vendors rarely volunteer any of them.
- Binary size. A native core adds megabytes per architecture. Ask for the per-ABI figure, not the total.
- Crash surface. Ask what the SDK does when the network is unavailable, when the process is killed mid-transfer, and when the device changes network mid-session.
- Store policy. Any vendor who guarantees you an outcome on Google Play or the App Store is guaranteeing something they do not control. The listing is yours and the disclosure obligations are yours. What a vendor can legitimately promise is that consent is enforced in the architecture and that the disclosure text is available for you to use.
On Windows there is a fourth: antivirus classification. Bandwidth-sharing agents get flagged as proxyware by some vendors, and an unsigned binary opening network connections is exactly what heuristic scanners react to. Anyone telling you this is a non-issue has not shipped on Windows. The mitigations are real but they are your work, and the Windows page covers them.
8. Can you test it without talking to a salesperson?
The single fastest signal about a vendor is whether you can get a device online today.
If evaluating an SDK requires a call, a contract and a minimum commitment, you cannot do the only test that matters: integrate it behind a flag, ship to 1% of users, and watch your crash-free rate and your retention curve for a week. That test is cheap and conclusive, and a vendor confident in their SDK makes it possible.
Our first 100 devices go live with no sales call, which exists precisely so that week costs you nothing.
What we are worse at
Fair is fair.
Bandwidth sharing pays less than a subscription and always will. If your app can sustain a subscription, run a subscription — the revenue per user is not close, and the per-download comparison shows the gap plainly.
It also pays nothing for users on hosting, datacenter or VPN IPs, and if your audience is developers or privacy-conscious power users, that exclusion will take a meaningful bite out of your qualifying device count. An app whose users are mostly on corporate VPNs is a bad fit and we would rather say so now.
And it is the only model on the menu that does something on a user's device the user cannot see happening. That is exactly why the eight questions above exist, and why we would rather you asked them of us than skipped them.
The afternoon version
- Pick two vendors and send both the eight questions above by email.
- Read the consent screens side by side.
- Integrate the one that answered better behind a feature flag.
- Ship to 1% of users.
- Watch crash-free rate, retention and uninstalls for seven days.
- Decide.
The step people skip is 4, and it is the only one that cannot be undone cheaply.
How it works is our long-form answer to most of the eight.
Your first 100 devices go live today.
No sales call, no approval to start. Sign up, drop the SDK in, and watch the first device appear in your dashboard.
Create your free accountFrequently asked
What is a passive income SDK?
A library you add to an app that pays you when your users opt in to relaying a capped share of their unused internet bandwidth for public web data collection. No advertisement is rendered and no paywall appears, so the revenue does not come out of the user experience the way ads or subscription gates do. Payment is typically quoted per user per month, and the SDK runs as a background task inside limits set by the vendor.
Which passive income SDK pays the most?
Published headline rates are close enough across vendors that the rate is rarely what decides your actual revenue. What decides it is the definition of a paid user: whether there is a minimum daily activity bar, whether a partial month pays proportionally, and which devices are excluded from counting at all. Two vendors quoting the same monthly figure can pay materially different amounts for the same install base. Ask each one how a paid user-day is defined before comparing headline numbers.
Are bandwidth-sharing SDKs safe for my users?
That depends entirely on the implementation, which is why the questions worth asking are about enforcement rather than intent. The ones that matter: are the bandwidth and data caps compiled into the binary or pushed from a server, can the SDK transmit anything before the user has accepted a consent screen they were shown, does it opt out or merely throttle when the device is under load, and what destinations are permanently blocked. A vendor who cannot answer those in writing has answered them.
Will a passive income SDK get my app banned from the app stores?
No vendor can guarantee an outcome on a store they do not control, and one who offers that guarantee is telling you something useful about themselves. Both major stores require that background network use is disclosed to the user and consented to, so the architectural requirement is that the SDK cannot transmit anything before explicit consent. The listing, the privacy declarations and the disclosure text remain your responsibility.
How do I test a monetization SDK safely?
Integrate it behind a feature flag and ship it to about 1% of your users, then watch your crash-free rate, retention curve and uninstall rate for a full week before widening. That test costs an afternoon and catches almost everything that matters. It only works if you can get devices online without a sales process, so whether a vendor allows that is itself a useful signal.