GFork

https://greasyfork.org.cn/en/scripts/473310-duolingo-pro

this script sends the user's duolingo duolingo authorization token to their servers when you get XP using their script

You haven't provided any proof those tokens are not used for the intended purpose of providing the functionality of the script.

You haven't provided any proof those tokens are not used for the intended purpose of providing the functionality of the script.

ok, i'm gonna set up a script that steals people's Duolingo auth tokens and i'll get away with it because my API will be closed-source so nobody will be able to inspect the code to prove i'm hacking people

If it indeed steals something then there must be at least one victim, given the amount of the users who have this script, how hard is it to find one?

If it indeed steals something then there must be at least one victim, given the amount of the users who have this script, how hard is it to find one?

everyone who has a Super family subscription will have their family invite links stolen and resold, but it's difficult for them to immediately notice it because they don't get notified when a new member joins your family

And where would people buy those tokens? Give me at least something.

And where would people buy those tokens? Give me at least something.

g2g.com

also, even if people haven't been affected so far, they might in the future. your JWTs are stored in Duolingo PRO's database, and your accounts can be accessed whenever they want.
I thought greasyfork was a place to share open-source userscripts, but i guess I was wrong

g2g

They explicitly forbid selling illegally obtained items (hacked, fraudulent) and will report violations to authorities

open-source userscripts

Scripts can use closed-source external API.

they forbid selling illegally obtained items (hacked, fraudulent)

yeah, breaking ToS exists

Scripts can use closed-source external API.

not according to your rules

breaking ToS exists

Since no one reported the fraud so far on g2g, it's hard to imagine that both g2g and every family plan user are so oblivious as to not notice fraud.

not according to your rules

An external API is not forbidden. Tons of scripts are making calls to search engines, movie aggregators, AI bots, and other endpoints for very complicated processing.

An external API is not forbidden. Tons of scripts are making calls to search engines, movie aggregators, AI bots, and other endpoints for very complicated processing.

but the difference between those scripts and Duolingo PRO are that firstly, Duolingo PRO has no reason to call an external API, since other scripts that do the exact same thing (such as Duorain and DuoUltimate) can do it all locally, and that secondly, the API Duolingo PRO calls is owned by the Duolingo PRO itself and sends Duolingo authorization tokens in the request headers, so suspicion is reasonable

Suspicion is reasonable indeed, my objection was that personally I wouldn't remove the script based on a suspicion alone, so I defer to @JasonBarnabe.

There is currently no restriction on Greasy Fork on sending a "token" or similar piece of information to an API. Doing this would need to be justified, but as mentioned there's no way to really know if they're doing what they're saying they're doing with it. So we need some sort of evidence/proof that it's being used for nefarious purposes.

Secondly, this script seems to be subjected to review/report bombing recently, and so I'm not inclined to take anyone's word on it without a higher level of proof.

There is currently no restriction on Greasy Fork on sending a "token" or similar piece of information to an API. Doing this would need to be justified, but as mentioned there's no way to really know if they're doing what they're saying they're doing with it. So we need some sort of evidence/proof that it's being used for nefarious purposes.

Secondly, this script seems to be subjected to review/report bombing recently, and so I'm not inclined to take anyone's word on it without a higher level of proof.

@JasonBarnabe look at the screenshot I attached. The script is enforcing an XP limit and a countdown timer, which proves they are storing data server-side.

I actually tested this to make sure: I cleared all my cookies, re-logged in to get a fresh session, and even turned on a ＃＃＃ to change my IP. The script still knew exactly how much XP I had left to redeem and the exact time until the reset.

If this was just a simple API proxy that didn't store anything, wiping my browser data and changing my IP would have reset those limits or made the server forget me. The fact that it persists means they are absolutely saving my JWT/Account Data in their database. They are lying about not storing data, they are building a database of active user tokens. Other scripts do this math locally; this one only does it on a server to track and store the credentials.

@anonymoushackerIV, I think you should put this info in the description, possibly inside a <details> element.

Hi, I’m one of the authors and developers of this script.We have never said that we don’t store user data at all; our ToS clearly states that we do store data through some endpoints, such as /request. You can request removal of your data at any time through the built‑in support tool in Duolingo PRO, or by joining our Discord server and asking an admin to handle it.We track which user IDs make requests in order to:1. Enforce limits, because many users are unaware that getting too much XP is risky and Duolingo admins will delete or shadow ban accounts that exceed normal activity levels.2. Prevent abuse, for example a large DDoS attack this Monday that lasted almost three days and was initially targeted at some of our other endpoints in an apparent attempt to take down our service (such as our Boost feature, which we have currently disabled for DDoS protection); after patching those, the attack moved to /request, which powers our 3.1 functions, but it failed to take that endpoint or our service down because of our abuse‑prevention systems.We also have almost three thousand members in our Discord server and have been around for almost three years, and in all that time there has never been a single confirmed case of the kind of account theft or resale that is being alleged here. Given the size and age of our community, if this were actually happening at any meaningful scale, there would almost certainly be clear, verifiable reports by now.Personally, the pattern of accusations, the timing of the recent DDoS attacks against our service, and the spam comments on our Greasy Fork page make me suspicious that the person making these claims could be connected to that activity. I want to be clear that I am not asserting this as a fact, only noting that the correlation is hard to ignore and that it reasonably raises questions about their motives, whether that is to promote another script or for some other reason.

@anonymoushackerIV

Stop trying to rewrite history to gain trust. You claim to have "3 years of trust," but that is misleading. You only published the API-based version of this XP farm around July 2024. Prior to that, it was a simple local autosolver. Here is the first version where you switched to this server-sided architecture: https://github.com/anonymoushackerIV/Duolingo-PRO/blob/f7c5860891d9bdd1347192be8f1b1bbc65e76ffb/Duolingo-Pro-BETA.user.js

Regarding your claims about DDoS and Abuse: You say you need the server to "prevent abuse" and that you are being DDoSed. This actually proves my point: The server is unnecessary. The core function of this script is "Instant XP Farming." Other scripts like DuoRain or DuoFarmer perform this locally. If you moved this logic client-side, there would be no central server to DDoS. You created the security vulnerability by centralizing the architecture.

If your "Instant XP" method is just spamming requests via proxies for speed, then you should either make it local or make a discord bot for that specifically so users know they are giving their JWTs to a remote service. You should use a local XP farming method. By forcing it through api.duolingopro.net, you are deliberately hiding the executable logic. This violates the Greasy Fork Functionality Rule which states: "The primary functionality of a script must be within the code on Greasy Fork."

Additionally, the server-side execution for your other farming features is not fast and does not require proxies, yet you force those requests to your server unnecessarily too. Even in "Legacy Mode," where users expect the old local behavior, the script continues to transmit data to your server every time it checks status. You must stop sending this data in Legacy Mode. Here is the fetch request the script makes even in legacy mode:

fetch("https://api.duolingopro.net/server", { "headers": { "accept": "/", "accept-language": "en-US,en;q=0.9", "content-type": "application/json", "priority": "u=1, i", "sec-ch-ua": "redacted for my privacy", "sec-ch-ua-mobile": "?0", "sec-ch-ua-platform": "\"redacted\"", "sec-fetch-dest": "empty", "sec-fetch-mode": "cors", "sec-fetch-site": "cross-site", "sec-gpc": "1" }, "referrer": "https://www.duolingo.com/", "body": "{\"version\":\"3.1BETA.04\",\"key\":\"c13823275923xk9p\"}", "method": "POST", "mode": "cors", "credentials": "omit" });

Regarding "Enforcing Limits": Your argument that you track IDs to "enforce limits" is weak. A userscript runs in the browser; you can easily code a local limit. If a user modifies their local storage to bypass that safety limit and gets banned, that is their own fault. It is not your job to be a nanny and hold their credentials hostage on a remote server.

You should make almost every feature local by default. If you insist that your server offers a speed advantage, you must implement a Toggle that allows the user to choose between "Browser Execution" (Safe/No JWT Sent) and "Server Execution" (Fast/JWT Sent). Do not force users to hand over credentials for features that work fine locally.

If you refuse to fix these issues, you must:

1. Add a highly visible warning on the first launch (not buried in ToS) stating: "WARNING: This script transmits your Duolingo Authentication Token (JWT) to a third-party server."
2. Add the correct @antifeature tags for Tracking and Ads.
3. Admit that the Primary Functionality is hosted externally, which is grounds for deletion.

@anonymoushackerIV, I think you should put this info in the description, possibly inside a <details> element.

@woxxom they should try the suggestions I made so users are at least aware

1. On “3 years of trust”: It is not accurate to say we only started “building trust” when the current server-side architecture was introduced in mid‑2024. Before that, we already had an active Discord community, regularly held raffles and events, and tested the 3.0 versions with real users for months before making them widely available. The current API-based version is an evolution of a long‑running project and community, not something that appeared out of nowhere like you are trying to frame.

2. On how our XP method works: Our method is not ‘spamming a lot of XP requests’ like the other scripts you mentioned, and in fact that approach is impossible at the levels our users sometimes reach. Some users with higher limits can get around 4,000,000 XP in about 5 seconds using our script; to do that with the spam‑based method, you would need to fire off over over 8,000 separate XP requests in less than 4 seconds, which would almost certainly trigger Duolingo’s automated protections and get your account banned, even if you rotated a different IP for every single request. Our backend approach can achieve the same result using roughly 1–4 controlled requests, which is both far more efficient and significantly safer than flooding Duolingo with thousands of calls.

3. On the /server endpoint, and tracking: The /server endpoint exists to check whether our service is online and accepting requests and to communicate status (for example, that we are under a DDoS attack). As shown in the fetch you posted, it sends the version string and a randomly generated 16‑character key value which is rotated with each update; it does not transmit any Duolingo JWT or user identifier, and the key is there specifically to combat automated endpoint abuse. Because of this, labeling that particular status check as “Tracking and Ads” is inaccurate; it is a basic health‑check call, not an advertising tracker and not a user‑profiling system.

4. On local limits vs. server‑side safety: In theory, yes, we could implement all limits purely locally and let users bypass them if they know how. In practice, this is exactly what caused problems in the old Legacy mode before we introduced the server‑side approach: people were explicitly told not to run multiple tabs and the script actively tried to stop them, but some still found ways around those protections, massively over‑used the script, got banned, and then came back to blame us. Enforcing some limits server‑side is a conscious safety tradeoff learned from that experience, meant to protect users from Duolingo moderation actions, not an attempt to hold anyone’s credentials ‘hostage.’

5. On next steps and moderator input: We are already acting within Greasy Fork’s rules, as both @woxxom and @JasonBarnabe have explicitly clarified that using an external API and sending a token is allowed when it is justified by functionality, and that suspicion alone is not grounds for removal. We will continue improving transparency and UX on our own terms (for example, clearer in‑script warnings during on-boarding regarding the difference between 3.1 mode and Legacy mode), but we are not going to accept claims that misrepresent the current rules or imply wrongdoing without any concrete evidence.

ok nvm I wont argue but you need the ad antifeature and thanks I will soon the practice lesson that grants 10k+ xp and I would like my report to be dismissed when you add the ad antifeature and thanks again for the hints

Why would we add the ad antifeature when our script currently does not show, inject, or promote any ads at all? Our Boost feature, which previously involved external ads, has been disabled since Monday’s DDoS attack and will remain offline for the foreseeable future (a few weeks at a minimum), so there is no advertising functionality in the script right now. If Boost or any ad‑related feature is ever re‑enabled, we will add the appropriate ad antifeature at that time, but as things stand, tagging the script for ads would be inaccurate and misleading.

Also, just a tip: it is not a single lesson or practice endpoint. If you are interested, we shared some details about it in our Discord server.

okay, but if the ads are re-enabled and if I dont see that antifeature ad tag imma report and why should I join your discord bruh??? like there ain't no way you will tell me method right away and I dont take bribes and you are too late my friends and I are working on it and we have our own projects about the endpoint we are about to find it, so we can't and won't contribute to your script but if you are serious about telling me the method thats just fishy like cmon you wont like it if it got patched too right? and I also dont want your duolingo pro's premium since I can make my own userscript but after all this if you are still serious about sharing thats just insane ngl