Paste a mint into Telegram, get a scored rug-risk report back in seconds. This tutorial walks the open-source rug-check-telegram-bot starter: zero dependencies, ~150 lines of Node, a free MadeOnSol API key, and a transparent 0–100 score where every point is attributed to a named factor — mint authority, liquidity depth, LP burn, bundled launch, deployer track record.
Every data-powered product hits the same licensing question sooner or later, usually at the worst possible moment: after the feature has shipped. You built a terminal that shows rug scores, a bot that surfaces smart-money flow, a dashboard your users pay for — and then a partner asks for "just the raw feed," or an investor asks whether you actually have the right to sell what you're selling.
This guide maps the territory before you're standing in it. It uses MadeOnSol's own licensing structure as the concrete example, but the three-zone model below is how essentially every serious data vendor works — so it doubles as a checklist for evaluating anyone's terms.
The three usage zones
Zone 1 — internal use. Your systems consume the data to make decisions: your bot gates entries on a rug score, your backend enriches alerts with deployer history, your quant process backtests against KOL flow. No third party ever sees a raw API response. On virtually every vendor's standard terms — including our Free, Pro, and Ultra plans — this is simply allowed.
Zone 2 — user-facing display. Your users see features built from the data: a risk badge in your terminal, a PnL chart in your bot, an alert in your Discord. This is the zone most embedders live in, and it's where terms differ meaningfully between vendors. MadeOnSol's standard plans explicitly allow using API data "within the user-facing features of your own application" — your product, your UI, powered by our data. Some vendors require attribution here; some price it as a separate tier. Read the words, not the pricing page.
Zone 3 — redistribution. The data itself is what you deliver: you expose an API to your customers, sell datasets or exports, syndicate a feed, or present the data as your own product. On standard plans this is prohibited essentially everywhere — ours says no reselling, sublicensing, or making raw responses or bulk data available to third parties as data — and this is the zone where a written data license becomes mandatory.
The bright line is easy to remember: features are yours, data is licensed. Turning data into a feature your users interact with is embedding. Passing the data through is redistribution.
Why vendors care (and how they check)
A data layer like this — labeled KOL wallets, scored deployer histories, an MEV-stripped DEX firehose — is the accumulated moat. Uncontrolled redistribution means one paying customer becomes a free mirror for everyone else. That's why standard terms also prohibit accumulating responses into a shadow database, and why serious vendors (us included) reserve the right to watermark API responses so a leaked dataset traces back to its source key.
None of this is adversarial — it's what makes the standard tiers cheap. You're paying for usage, not for a data license, and the price reflects that.
What an Enterprise data license actually covers
When your product genuinely needs Zone 3, the deal changes shape: a written agreement rather than a checkout page. MadeOnSol's Enterprise tier is annual-contract (invoice or USDC) and covers the rights self-serve plans can't grant:
- White-label — serve the intelligence under your own brand, no attribution.
- Redistribution rights — expose data to your customers through your own API or product, scoped in the agreement.
- Bulk export and extended caching — hold and process data beyond the operational caching standard terms allow.
- Dedicated rate limits — beyond Ultra's 100k requests/day, sized to your product.
- Uptime SLA, custom endpoints, and a priority support channel — because your product's reliability now depends on ours.
If you're weighing this against building the pipeline yourself, run the numbers in our build-vs-buy cost comparison first — the honest answer is that a license is almost always cheaper than the third engineer you'd hire to keep Geyser plugins alive.
Five questions to ask any data vendor before you build
- Can my users see the data in my UI on a standard plan? (If the answer is vague, assume no.)
- What caching is allowed? Operational caching is normal; accumulating a historical database usually isn't.
- What exactly upgrades me into "redistribution"? Get the bright line in writing before an integration decision depends on it.
- Is white-label a product tier or a custom contract? Custom contracts are slower but scoped to what you actually need.
- What happens at termination? A serious agreement says what you may retain; silence here bites later.
Where to start
Nobody starts at Enterprise. The sane path is the one our standard terms are built for: prototype on a free key, ship your user-facing features on Pro or Ultra, and open the licensing conversation when a concrete Zone 3 need shows up — a partner integration, a reseller request, a white-label deal of your own. The builder's guide to embedding Solana memecoin intelligence covers the technical half of that journey (REST, WebSocket, webhooks, MCP); this post is the legal half.
Two related guides show what this looks like in practice: the Telegram bot and terminal SaaS data-layer guide covers the endpoint-by-endpoint architecture for the most common Zone 2 product, and our look at DexScreener's API restrictions on competing products shows why "no reselling" and "no competing products" are two different clauses worth reading separately.
When you're there: madeonsol.com/pricing has the Enterprise band, and scoping starts with an email to [email protected] — what data, what surface, what volume. The full usage terms live in our Terms of Service.
