Stop cluttering your app
with ads.
Meerkly monetises the bandwidth your users already have, not their attention. The SDK has no interface, shows nothing to anyone, and runs only for the people who chose to turn it on.
What your install base is worth without ads.
Bandwidth revenue scales with users who stay online, not with impressions you have to interrupt someone to serve.
What is your install base worth?
Only the users who say yes share anything, and only while your app is running. Every figure here is one your own analytics can answer.
That is $76.10 per thousand users who opted in.
A year of it is $17,533 — and you ship no ads to get it.
The opt-in rate is yours to move. Ask well, at the right moment, and explain what it pays for — this is the one input on the page you control directly.
An estimate, not an offer. Real throughput depends on demand for your users’ locations and how long sessions actually last. Every app is metered separately, so you see the real number per app from the first day it ships.
Your users decide. Always.
Meerkly cannot turn itself on. It has no interface to ask with and no way to start without your code saying so — so the consent your users give is real, and it is yours to design.
The SDK has no interface
It draws nothing, shows nothing and asks for nothing. There is no banner, no interstitial, no consent sheet of ours to clash with your design. Whatever your users see, you wrote it.
Nothing runs until you call start()
No background registration, no pre-flight, no quiet head start on install. The connection is opened by your code, at the moment you choose — which is what makes a real opt-in possible.
stop() is immediate and complete
One connection closes and it is over. Nothing queues, nothing drains, nothing lingers for a grace period. A user who turns it off is off.
The device, never the person
We do see the device: its operating system, processor, hostname and SDK version, plus the network and city it connects from. What we have no way to see is content — nothing your users browse, type or store, and nothing at all about what they do inside your app.
What that looks like in your app
Bind sharing to a setting your users control and the whole opt-in is two calls. Turn it on when they say yes, off the moment they change their mind — no server round-trip, no waiting for a flag to propagate.
Disclose it in your store listing and privacy policy, ask plainly, and keep the switch somewhere they can find it again. Meerkly gives you the switch; the wording is yours, and it should be.
// The opt-in is yours. The switch is one call.
if (await settings.sharingEnabled()) {
await client.start();
} else {
await client.stop();
}Before anything else: what your users are actually sharing.
Nothing about what your users browse, store or do inside your app is visible to us. The SDK has no telemetry and no interface.
The exit refuses anything that is not a routable public address, so nothing reaches a printer, a NAS or a router behind your user's front door.
Bytes are counted by us as they move, not reported by the device — so neither you nor we are trusting a client's own arithmetic.
A publisher id and one call.
Create an id in the dashboard, drop it in, and call start(). The id is a public identifier — it says which account earns and grants access to nothing, so committing it is not a credential leak.
npm install @meerkly/sdkimport { ProxyClient } from "@meerkly/sdk";
const client = new ProxyClient({
publisherId: "pub_your_publisher_id",
});
await client.start();5 lines. That is the whole integration — the SDK opens one connection, shares bandwidth in the background, and stops the moment you tell it to.
Every binding, from one core
The SDK is a single Rust implementation with generated bindings, so behaviour does not drift between platforms.
| Platform | Language | Package | How it is built |
|---|---|---|---|
| iOS | Swift | Coming soon | uniffi · SwiftPM target |
| Android | Kotlin | Coming soon | uniffi via JNA · per-ABI .so |
| Desktop & server | Node | @meerkly/sdknpm | napi-rs · prebuilt binaries |
| Backend | Python | Coming soon | uniffi · pip |
| Backend | Go | Coming soon | uniffi · cgo |
| Backend | Ruby | Coming soon | uniffi · gem |
| Native | Rust | meerkly-sdkcrates.io | the core itself |
Both published packages are MIT or Apache-2.0. The rest are built and tested from the same core and will appear here as they reach a registry.
Shipping more than one thing? Give each app its own publisher id and its traffic is metered separately — rotate a key whenever you like, and the app’s history follows it.
What every developer asks first.
What do my users actually see?
Nothing from us. The SDK has no interface of its own — no banner, no sheet, no notification. Whatever your users see is what you built, which means the opt-in reads like the rest of your app instead of like an advertising SDK bolted on.
Do I need their consent?
Yes, and you should want to. Disclose it in your store listing and privacy policy, ask plainly, and keep a switch somewhere they can find again. The SDK cannot start itself, so an opt-in you honour in code is an opt-in that actually holds.
We do not ship the dialog, and that is deliberate — the relationship is yours, the wording should match your product, and the app stores expect the developer to own it.
Will it eat their battery or their data?
The SDK holds a single connection and does no work when no traffic is being routed through it. But shared traffic is real traffic: on a metered connection it counts against your user’s plan.
There is no Wi-Fi-only mode or data cap in the SDK today, so if that matters for your users, gate start() on your own reachability check and stop when they drop to cellular. You are already holding that switch.
How is my revenue calculated?
Revenue is on the bytes your users’ connections carry: the tunnel to our gateway is measured on the wire, the site-side payload is counted as it moves with a fixed header allowance added — never reported by the device — and the total is priced at $0.10 per GB. Usage is attributed to the publisher id that was connected, so each app’s earnings are separate and visible from the first day it ships. Settled earnings freeze the rate they were priced at, so a rate change never moves money already earned.
What if I rotate or retire a publisher id?
Rotating gives the app a new id and keeps the old one attached to its history, so usage metered under any id the app has ever used still belongs to that app. Builds already in the wild keep earning under the id they shipped with.
Is the SDK open source?
The two crates the SDK is made of are: meerkly-sdk and meerkly-protocol, both on crates.io under MIT or Apache-2.0. Every other binding — Node, Swift, Kotlin, Python, Go, Ruby — is generated from that same core, so you can read exactly what runs on your users’ devices. The gateway is closed.
What does it add to my binary?
A native library and a thin binding — no ad renderer, no webview, no tracking framework, and no third-party network calls of its own. It opens one outbound QUIC connection to our gateway and nothing else, and it writes nothing to disk.
Can I try it before I ship it?
Yes. Create an account, take a publisher id, and run the SDK on your own machine — the Node package is one npm install, the Rust crate one cargo add. You will see the bytes and the earnings in the dashboard against that id before a single user is involved.
Your users already pay for the bandwidth. Let it pay you back.
Create an account, take a publisher id, and run the SDK on your own machine before a single user is involved.