VALORANT rank yoinker: an overlay for rank and equipped skins

What the overlay shows and what it needs to run

VALORANT rank yoinker is a Python application which retrieves the VALORANT rank and the players' equipped skins during a match. The project is referred to by the abbreviation vRY in its own documentation.

The output is a small set of fields. The project documents a table with the current skin, the current rank, the rank rating, the peak rank and the account level, and the screenshots in the documentation show the same set of images for each. The account level in particular is the progression of the account, which is separate from the competitive rank.

The one hard requirement is stated plainly at the top of the usage section: VALORANT must be open. This is not a web scraper that queries a public endpoint. It reads the state of a local game client, which is why it can show the equipped skin and the live rank without polling a service.

The project is distributed in two forms, a bundled release and a source checkout, and the repository also has a GitHub Actions workflow that builds the executable from the main branch so a successful run leaves a downloadable artifact.

The users are streamers and small broadcast teams who want the rank and skin on screen during a match, and the repository carries a Discord shield, a downloads badge and a community Discord link, which is the profile of a fan tool rather than a professional broadcast tool.

The bundled release: install, extract, run

The bundled release is the shortest path and the documentation lists three steps.

First, download the Microsoft Visual C++ Libraries. Second, download the release from the releases page. Third, extract all files, and the instruction to extract all of them is worth taking literally, because the build bundles extra files alongside the executable. Finally, run vRY.exe.

The reason the Visual C++ runtime is a separate first step is the packaging tool. The build uses cx_Freeze, and the setup.py in the repository shows how the executable is assembled:

from cx_Freeze import setup, Executable
from src.constants import version

and the executable itself is defined with the project icon and a target name:

    executables = [Executable("main.py", icon="./assets/Logo.ico", target_name="vry.exe")],

That target name is why the released binary is called vRY.exe while the repository is named differently, and it is also why the extracted bundle contains more than one file.

The build options in the same file list the packages that get bundled, which is effectively the dependency list of the application: requests, colr, InquirerPy, websockets, pypresence, nest_asyncio, rich and websocket_server. The includes are configurator.bat and updatescript.bat, and the excludes are tkinter, test, unittest, pygments and xmlrpc. That is a compact picture of a terminal-oriented Python app with a Discord presence integration and a rich console interface.

Running from source and compiling your own executable

The source route is documented in four steps. Download Python 3.11 or 3.10, making sure it is added to the PATH, which the documentation notes is an option on installation. Download the source. Run the INSTALL.bat file, or use pip install -r requirements.txt in the terminal. Then run the START.bat file, or use python main.py in the terminal.

The .bat wrappers are conveniences for the Windows audience, and the terminal equivalents are the same two operations, which means the project is usable on any platform with the right Python version.

Compiling your own executable takes three steps: pip install cx_Freeze, then python setup.py build, and then open the new Build folder and find vRY.exe.

Two configuration notes follow. You can change the desired weapon by editing the gun in config.json, or by deleting the file so vRY prompts you again, and the project publishes a page at vry.netlify.app/matchLoadouts listing all skins.

The pinned dependency list in requirements.txt is short and mostly exact, which is what you would expect from a project that ships as a frozen executable. It includes certifi, charset-normalizer, Colr, idna, inquirerpy, markdown-it-py, mdurl, nest-asyncio, pfzy, prompt-toolkit, Pygments, pypresence, PyYAML, requests, rich, urllib3, wcwidth, websocket-server and websockets.

The pypresence entry is the Discord integration, and the rich and prompt-toolkit entries are the interactive terminal pieces, with InquirerPy and pfzy for the prompts and wcwidth for character widths in the console output.

How it gets the data and the streamer mode constraint

The documentation addresses the obvious question about this kind of tool directly, under the heading What about that Tweet.

The tweet in question, from the official PlayVALORANT account, details Riot's API policies and outlines how applications are not allowed to expose data hidden by the game client. The project then states that as of Version 1.262, vRY respects streamer mode.

That is the key design constraint and it is worth being precise about what it means. Streamer mode is a VALORANT setting that hides sensitive information from a broadcast capture, and the project reads from the local client but does not surface what the client is hiding. So the rank, the rating and the equipped skin are available, while anything the player deliberately masked is left alone.

The acknowledgements name the services the project builds on. Valorant-API.com is listed first, along with Hamper and D3CRYPT, which is where a developer would look to see what the project calls and what the community around it provides.

There is also a configurator.bat in the tree and a status.json file, alongside the setup and update scripts, which suggests the tool has a configuration step and reports state somewhere the overlay can read it. The documentation does not describe the internal mechanism of that exchange, so the honest statement is that the data path runs through the local client and the community services named in the acknowledgements, and that the streamer mode behaviour is the documented commitment to Riot's policy.

The final release, the community forks and the disclaimer

The state of the project is stated in a caution block at the top of the documentation, and it is the first thing a potential user needs to know.

vRY has published its final release, no changes will be made to the code, and community forks may be maintained. There is a COMMUNITY.md file in the repository for exactly this purpose.

That is an unusual and rather responsible way to end a project. The code is frozen at a known good state, the original author is not taking further change requests, and anyone who needs different behaviour has a documented place to look. For a tool whose value is its simplicity, that is a sensible ending rather than an abandonment.

The release history shows the pace. Version 2.80 came on 2025-03-07, 2.92 on 2026-01-08 and 2.94 on 2026-05-21, and the last push was on 2026-05-21, the same day. So the last change to the tree is about five months old, and the repository is not archived, which means the code is still there to read, fork and build even though the author has stopped changing it.

The disclaimer is explicit. The project is not associated with or endorsed by Riot Games, and Riot Games and all associated properties are trademarks or registered trademarks of Riot Games, Inc. It also says that whilst effort has been made to abide by Riot's API rules, use of the software is done at your own risk.

The licence is ISC, which is short and permissive. The LICENSE file is at the repository root, and you should read it for the exact terms. For a piece of software distributed as a frozen executable to end users, an ISC licence is a straightforward choice.

Where VALORANT rank yoinker is the wrong tool

The first limit is the hard dependency on a running game. This is a local overlay for a live session, not a service, not a tracker, and not something that can run on a server watching a match feed. If you want a system that records rank history over a season, or a website that shows a profile, none of that is here.

The second is the end of development. The author has stated that the final release is out and that no changes will be made to the code, so if VALORANT ships a client update that changes the local state this tool reads, the tool does not follow. Riot ships client updates frequently, and a project that has explicitly stopped changing cannot track them.

The third is the scope of what it displays. Rank, rank rating, peak rank, account level and the equipped weapon skin is the feature set, and the documentation does not describe anything beyond that.

The fourth is the policy layer. The project relies on community services including Valorant-API.com, and it operates under a policy that forbids exposing data hidden by the game client, which it says it respects as of version 1.262. Any change to that policy or to the behaviour of those services lands on a frozen codebase.

Compare that with a purpose-built stream overlay from the broadcast software side, which is configured rather than compiled and can be adjusted without a new binary. The difference in approach is that this project reads the game client directly and freezes the result, which is how it keeps a small footprint and a simple install, and which is also why it cannot adapt when the game changes.

How to fork it, and what to check before you rely on it

The documentation spells out the fork workflow for a small change, which is the most useful thing in it for anyone who needs to adjust the behaviour.

Fork the project. Change the code in your forked repository. Let the GitHub Actions workflow build vRY.exe for you. Download it and test it. Submit a pull request if you would like your change included in future releases, though with the project frozen that last step is now a courtesy rather than a route to a release.

The community fork mechanism is what you use instead. Since the original code will not move, a fork that tracks the game client is the only way to keep the tool working through a client update, and COMMUNITY.md is where those forks are listed.

What to verify before you depend on it is short. Install the bundled release with the Visual C++ libraries, run vRY.exe with VALORANT open, and confirm the five displayed values, the skin, the rank, the rating, the peak and the level, are correct on your own account. Then check that the values match what you see in the client, because a stale or mismatched readout in a broadcast is worse than no readout. If you intend to modify it, build from source with Python 3.10 or 3.11 first, so you know the toolchain works before you change anything.

And read the disclaimer as a practical matter rather than boilerplate. The project is not associated with or endorsed by Riot Games, and use is at your own risk even though effort has been made to abide by Riot's API rules. For a public stream, that is a fact worth knowing before you put it on screen.

Editorial conclusion

VALORANT rank yoinker fits a streamer or a small team that wants a live rank and skin readout in a broadcast overlay and is content to run a local Python process alongside the game. It does not fit a project that needs ongoing development, because the author states the final release has been published with no further code changes, and it does not fit a workflow that depends on data the game client hides, since the project says it respects streamer mode. Before you rely on it, run the bundled release with VALORANT open, check the community forks listed in COMMUNITY.md if you need changes, and read the disclaimer, which states the project is not associated with or endorsed by Riot Games.

Frequently asked questions

Official sources

1. License: ISC
2. Project website
3. README
4. Releases
5. zayKenyon/VALORANT-rank-yoinker on GitHub