Traadence's Pokemon Trading Bot is a locally run desktop application for collectors who want repeatable Link Trades without rebuilding each Pokémon or navigating every menu by hand. A request starts in the local builder, passes legality checks, becomes a game-compatible Pokémon object, enters a queue, and is delivered through a connected Nintendo Switch. The connection layer uses sys-botbase or a compatible USB path to send controller commands and read or write game memory. For Pokémon data structures and legality logic, the application can rely on PKHeX rather than duplicating generation-specific rules. The result is a desktop trade station with explicit inputs, visible job states, retries, reusable recipes, and per-game configuration.
Build the requested Pokémon locally, validate it, queue it, then let the connected console complete the Link Trade sequence.
Core Features
| Feature | Description |
|---|---|
| Pokémon Builder | Manual editing is error-prone when species, form, nature, ability, IVs, EVs, four moves, held item, ball, trainer data, language, level, shiny state, ribbons, and marks all have to agree. The builder keeps those fields in one local request model and applies generation-aware limits before a job can advance. |
| Legality Validation | Invalid move, ability, event, encounter, or metadata combinations can cause a trade request to fail before delivery. The validator checks each generated object against known legality rules and blocks combinations that the configured game profile cannot accept. |
| Switch Connection Layer | Repeated manual menu input and memory handling make high-volume trading inconsistent. The bot uses network or USB communication with the console layer, with SysBot.NET providing a proven reference for asynchronous Switch automation around sys-botbase. |
| Per-Game Offset Profiles | Game patches can move memory locations and make a previously valid injection path unsafe. Each supported title gets its own versioned offset profile so Scarlet/Violet, Sword/Shield, BDSP, PLA, and other configured games do not share addresses blindly. |
| Link Trade Automation | Watching the screen and pressing every button by hand wastes time and invites inconsistent timing. The bot creates a request code, navigates the trade flow, waits for a partner, submits the prepared slot, and records completion or failure. |
| Queue and Retry State | Multiple requests are difficult to manage when there is no durable state. Every job moves through pending, connecting, trading, complete, or failed states, with timeout handling, bounded retries, and session logs for diagnosing unsuccessful runs. |
| Multi-Bot Profiles | One process should not confuse device state when several consoles or emulator instances are active. Separate bot profiles isolate connection settings, game offsets, queue ownership, and execution state per instance. |
| Local Recipes and History | Re-entering common builds creates unnecessary mistakes. Saved recipes restore validated configurations, while local trade history records what was generated, which profile handled it, and whether the run completed. |
Switch Link Trade Automation
The trade runner is built around the same actions a user performs in-game, but it turns them into deterministic states. For Pokémon Scarlet and Violet, Nintendo documents the normal online trading path through the Poké Portal and Link Trade flow in its multiplayer support guide. The desktop app keeps that game-facing sequence separate from memory placement, so controller timing, partner detection, and object injection can fail independently and produce a useful log entry instead of a single opaque error.
Operational Limits That Matter
| Constraint | How the application handles it |
|---|---|
| IV range | Each stat accepts 0–31; out-of-range values are rejected at input. |
| EV allocation | Each stat accepts 0–252 with a 510 total cap enforced before generation. |
| Moveset size | Exactly four move slots are exposed, with availability filtered for the selected game and species. |
| Job lifecycle | Five visible states—pending, connecting, trading, complete, failed—make queue behavior inspectable. |
| Device scaling | Each active Switch or emulator instance runs under its own bot profile and queue assignment. |
| Rate controls | Configurable spacing and retry ceilings limit repeated automated attempts; they are operational safeguards, not a guarantee against platform enforcement. |
Tech Stack
| Layer | Choice | Why it fits this build |
|---|---|---|
| Desktop application | C# / .NET | The surrounding Pokémon automation ecosystem is already C#-heavy, and PKHeX exposes Pokémon core data structures in the same runtime. |
| Console firmware layer | Atmosphère + sys-botbase | Atmosphère provides the custom firmware environment in which the bot sysmodule runs; sys-botbase supplies remote control and memory access. |
| Trade orchestration | Async worker queue | Long partner waits should not freeze the local UI. Each bot worker owns one device session while the queue records state transitions and retry counts. |
| Local persistence | SQLite | Recipes, history, device profiles, offsets, and job logs stay on the operator machine without requiring an external service. |
| Validation | PKHeX.Core legality routines | Using established generation-aware structures reduces duplicated rule logic and makes version updates easier to isolate. |
{
"connection": {"mode": "usb"},
"game": "SV",
"queue": {"retryFailedTrades": true},
"safety": {"rateLimitEnabled": true},
"offsetProfile": "sv-current.json"
}
Project Directory
pokemon-link-trade-desktop/
├── src/
│ ├── DesktopApp/
│ │ ├── App.xaml
│ │ ├── MainWindow.xaml
│ │ └── ViewModels/
│ │ ├── TradeQueueViewModel.cs
│ │ └── PokemonBuilderViewModel.cs
│ ├── Core/
│ │ ├── Models/
│ │ │ ├── TradeJob.cs
│ │ │ └── PokemonRecipe.cs
│ │ ├── Validation/
│ │ │ └── LegalityService.cs
│ │ └── Queue/
│ │ ├── TradeQueue.cs
│ │ └── RetryPolicy.cs
│ ├── Switch/
│ │ ├── SysBotConnection.cs
│ │ ├── UsbConnection.cs
│ │ ├── TradeNavigator.cs
│ │ └── Offsets/
│ │ ├── sv-current.json
│ │ ├── swsh-current.json
│ │ ├── bdsp-current.json
│ │ └── pla-current.json
│ └── Storage/
│ ├── AppDbContext.cs
│ └── Migrations/
│ └── InitialSchema.cs
├── config/
│ ├── appsettings.example.json
│ └── bot-profiles.example.json
├── tests/
│ ├── LegalityServiceTests.cs
│ ├── TradeQueueTests.cs
│ └── OffsetProfileTests.cs
├── logs/
│ └── .gitkeep
├── README.md
└── pokemon-link-trade.sln
Use Cases
- Repeat a competitive build accurately. Save a validated recipe once, then re-run the same species, nature, IV, EV, moves, item, and trainer fields without re-entering them.
- Process several requested trades in order. Put prepared jobs into the local queue and see whether each request is pending, connecting, trading, complete, or failed.
- Operate more than one console cleanly. Assign separate game, connection, offset, and queue profiles so parallel bot instances do not share device state.
- Recover from a failed partner connection. Let bounded retry rules reattempt timed-out jobs while preserving the failure reason and session log for inspection.
Ecosystem Scale and Safety Boundaries
Game-profile maintenance should follow the titles actually deployed with the tool, not assumptions about one universal memory layout. For ecosystem context, Nintendo publishes Switch software sales data and its FY2026 financial briefing. We use those sources to track title relevance only; they are not evidence of bot usage or account safety.
Automation also carries platform risk. The SysBot.NET project explicitly warns that continuous automated online behavior can be detected and penalized. This application therefore exposes request spacing, retry ceilings, and explicit logs, but it does not claim that legality checks or rate limits prevent Nintendo-side enforcement. For offset updates, additional profiles, or device-specific changes, bot customization and deployment can be handled against the same local project.
How to Automate Link Trades Using Traadence's Pokemon Trading Bot
Download & Set Up the Project
Download, set up, and install Traadence's Pokemon Trading Bot to get the project running. If you hit any difficulty, contact us here.
Open a Bot Profile
Launch the desktop app, choose the configured Switch or emulator profile, and confirm the connection state plus selected game version.
Build and Queue the Trade
Select species, form, nature, ability, IVs, EVs, moves, item, trainer fields, shiny state, and marks; validate, then add the request.
Start the Queue
Press Start Queue. The worker connects, runs the Link Trade sequence, updates job status, and writes completion or failure details to local history.
Keeping Game Profiles Current
Offsets and legality data should be treated as versioned dependencies, not hard-coded constants scattered through the UI. A game update can invalidate a memory profile even when the desktop application itself still launches. The project keeps offset files separate, validates the selected profile before a trade worker starts, and records the active game version in session logs. The SysBot.NET wiki is a useful reference for connection behavior and Pokémon bot configuration patterns. When a patch changes offsets or a new title is added, ongoing bot maintenance can update the profile without rewriting the queue, builder, or storage layers.
Questions
How does the bot validate a Pokémon before trading it?
It validates the generated Pokémon object before the trade job can enter execution. The check covers generation-specific structure, moves, abilities, encounter or event constraints, and related metadata through established legality logic such as PKHeX.Core. A failed check returns the request to the user instead of sending a known-invalid object to the console.
Which Pokémon games can the bot run with?
The application uses separate game profiles because each title has different memory offsets and trade behavior. The delivered profile architecture covers Scarlet/Violet, Sword/Shield, Brilliant Diamond/Shining Pearl, Legends: Arceus, and Let's Go Pikachu/Eevee when the matching offsets and navigation profile are verified; one game's addresses are never reused blindly for another.
Can I run more than one trade bot at the same time?
Yes, when each active Switch or emulator instance has its own connection and game profile. The queue assigns work to a specific bot worker, keeping offsets, connection state, retries, and logs isolated so one device does not overwrite another device's session state.
Does legality validation prevent Nintendo account penalties?
No. Legality validation checks whether the generated Pokémon data is compatible with known game rules; it is not an account-safety guarantee. Automated online behavior can still be detected or penalized, so the application includes spacing and retry controls while leaving enforcement risk explicit.