GoyGram runs Telegram Bot API and MTProto in one Python runtime with a Rust core

A single runtime for two protocols

GoyGram is a new open-source Telegram framework for Python that runs both of Telegram's protocols — the Bot API and MTProto — inside a single asyncio process. According to the project's announcement on dev.to, the cryptography and TL serialization work has been moved out of Python into a compiled Rust extension. The framework is available on GitHub under the AGPL-3.0 license, with separate documentation hosted by the project.

Two transports, historically two libraries

Telegram offers two very different ways to build software against it: the Bot API, the standard interface most bots are built on, and MTProto, the lower-level client protocol that Telegram's own applications use. As the announcement notes, that split has divided the Python ecosystem — aiogram and python-telegram-bot are Bot API only, while Telethon and Pyrogram speak MTProto only. Anything that needed both sides, such as a bot that also operates as a logged-in user client, meant running two libraries, two event loops and two sets of session state.

GoyGram collapses this into one process, one loop and one dispatcher. The transport is selected per operation, and the announcement says a single handler can serve both protocols. On top of that sit multi-session support, filters, FSM state machines, transport routing and an event pipeline.

The Rust core

The performance argument rests on where the hot code runs. The announcement states that AES-256-IGE and AES-256-GCM operations are implemented in Rust, built with LTO at opt-level=3.

The post includes benchmarks from a single VPS running Python 3.11. Cold import is claimed at 87 ms, against 3.1 s for aiogram, 477 ms for Pyrogram and 298 ms for Telethon. Memory after import is claimed at 12 MB of RSS versus 152 MB for aiogram, and AES-256-IGE throughput at 113 MB/s versus a default Telethon figure of 12 MB/s. These are self-reported numbers from one machine and one Python version, not an independent comparison, so the exact magnitudes should be treated as indicative rather than settled.

Schema-driven dispatch instead of generated code

Rather than shipping the hundreds of generated model files that typically accompany a TL-based library, GoyGram resolves methods from the TL schema at load time — a design the project describes as zero-overhead dynamic dispatch. Raw fields are then read lazily, only when a handler actually touches them, which the announcement links to the small import-time and memory footprint.

OpSec-first session handling

The framework also takes an opinionated stance on credentials. Sessions live in an AES-256-GCM vault keyed to the machine's ID, keys are zeroized from memory on logout, and login is terminal-only — via QR code, phone number or 2FA — so, according to the announcement, no token ever passes through a browser or desktop client. That last constraint is aimed at MTProto work in particular, since scripts that run against a personal account are only as safe as the session material they store.

Why it matters

The Python Telegram ecosystem has been organized around a transport choice for years, and that choice has dictated the library, the architecture and the deployment. GoyGram's bet is that the transport should be an implementation detail — picked per call, handled in one dispatcher — which is a genuinely different shape from what aiogram, python-telegram-bot, Telethon or Pyrogram offer.

Second, it continues a clear trend in the Python world, where projects like Pydantic, Ruff and Polars rebuilt their hot paths in Rust and reported large performance gains. Applying the same pattern to Telegram's crypto and serialization is a plausible route to Python-level ergonomics with native-level throughput.

Third, the security design — encrypted, machine-bound session vaults with keys zeroized on logout — targets a known weak spot of MTProto tooling, where mishandled session files can translate directly into account compromise. Keeping tokens out of browsers and desktop clients removes one common exposure path.

The caveats are equally real: the project is new, its benchmarks are self-reported on a single VPS, and the AGPL-3.0 license carries copyleft obligations that commercial adopters will need to review before building on it. What GoyGram has published so far is a promising direction, not yet a track record.