What Is MTProto? Telegram’s Custom Protocol Explained 2026

the short definition

MTProto is the proprietary network protocol Telegram built to handle all communication between its clients and servers. It operates below the application layer, managing encryption, session state, and data transport in a single stack that Telegram controls end-to-end. HTTPS layers application logic on top of TLS. MTProto doesn’t work that way. Its binary framing, obfuscated transport, and custom key exchange are purpose-built for mobile reliability and resistance to deep packet inspection.

the longer explanation

Nikolai Durov, co-founder of VK and brother of Telegram’s Pavel Durov, designed the first version of MTProto when Telegram launched in 2013. Criticism came almost immediately. Cryptographers including Matthew Green at Johns Hopkins published detailed takedowns pointing out that rolling your own cryptographic protocol from scratch is almost always a mistake, and that MTProto 1.0 had real structural weaknesses in its use of IGE-mode AES and its key derivation approach. Telegram took enough of that criticism seriously that they released MTProto 2.0 starting around 2017, migrating to SHA-256-based key derivation and addressing several padding oracle concerns that researchers had identified. The current protocol spec is published openly in Telegram’s official MTProto documentation.

What makes MTProto structurally different from HTTPS? Start at the transport layer. A standard HTTPS request is HTTP riding on top of TLS riding on top of TCP. TLS has a recognizable handshake: a ClientHello with a distinctive binary signature, cipher suite advertisements, and a certificate exchange. Every TLS connection announces itself to anyone watching the wire. MTProto supports multiple transports, and the default TCP variant sends framed binary data with no ceremony a passive observer can easily categorize. More importantly, Telegram ships an obfuscated variant that XOR-scrambles all bytes through a key derived from the initial connection handshake. To a DPI box reading the byte stream, an obfuscated MTProto connection looks like random noise with no identifiable protocol header.

The encryption uses AES-256 in IGE mode for MTProto 1.0 and a derived-key scheme in 2.0, with RSA-2048 for the initial key exchange with the server. Session keys are ephemeral. Each client-server session generates fresh material, so past sessions can’t be decrypted even if a future key is later compromised. This is a form of forward secrecy, though it differs architecturally from the Diffie-Hellman-based approach used in Signal or TLS 1.3, and cryptographers still debate the precise guarantees. The MTProto authorization key generation spec documents the full key creation and exchange process if you want to follow it step by step.

MTProto also handles delivery guarantees that HTTPS leaves entirely to the application. Telegram is a persistent messaging system, not a stateless request-response API. The protocol tracks message IDs, handles deduplication, manages acknowledgments, and retransmits on bad connections, all at the transport level. HTTPS punts all of that to the developer. MTProto bakes it in. This is part of why Telegram holds up on the kind of flaky mobile connections common in Nigeria, Pakistan, and the Philippines, where cellular coverage drops in and out and TCP sessions reset constantly. The protocol was built for that world, not for a stable fiber connection.

why it matters for telegram operators

If you’re running a Telegram account at any operational scale, MTProto is the protocol your account lives or dies on. The way a client speaks MTProto to Telegram’s data centers gives Telegram a continuous stream of behavioral signals. Official clients send specific TL (Type Language) constructors in a specific sequence. They handle server acknowledgments within expected timing windows. They connect to the correct data center for their registered region. They maintain session continuity across the lifecycle of a device. When something deviates from those patterns, Telegram’s anti-abuse infrastructure notices.

This is why account bans often have nothing to do with what a user sends. Why Telegram bans accounts frequently traces back to protocol-level and network-level signals: a client connecting from a data center IP block, a session sending an unusual density of API calls, or a device that rotates IPs mid-session in a way that breaks expected continuity. Telegram associates each MTProto session with an authorization key. That key is bound to a device fingerprint, which is bound to a network history. Change the network and the session may persist at the protocol level, but Telegram’s fraud detection sees the IP shift and makes its own judgment about what that means.

The obfuscated transport layer matters most for operators in restricted regions. Iran’s national filtering infrastructure, Russia’s TSPU system, and similar architectures use DPI to identify and block specific protocols. When Russia blocked Telegram between 2018 and 2020, Roskomnadzor’s approach combined IP-level blocking (targeting Telegram’s known data center ranges) with DPI-based fingerprinting. The obfuscated MTProto transport helped some connections survive because they didn’t match the signature the filtering systems were looking for. OONI measurement data from Iran’s 2018 crackdown showed inconsistent, patchy blocking that correlated with how well obfuscation held up against the specific DPI systems deployed. For operators in Dubai, Tehran, or Lagos, routing your Telegram session through a Singapore mobile IP doesn’t change the MTProto protocol, but it changes the IP reputation and geolocation signals that accompany every session handshake.

common misconceptions

MTProto means Telegram is end-to-end encrypted. It doesn’t, by default. MTProto handles encryption between your client and Telegram’s servers. Regular cloud chats are encrypted in transit and stored encrypted on Telegram’s infrastructure, but Telegram holds the decryption keys. The company can access the content of ordinary group chats and DMs if legally compelled, and has done so in specific cases under its stated privacy policy. End-to-end encryption in Telegram only applies to Secret Chats, which use a separate protocol layer (built on MTProto’s transport) where keys never leave the two devices. Most users never use Secret Chats. Most bots never can. This distinction matters enormously if you’re an operator with confidentiality requirements.

MTProto is the same thing as a VPN or proxy. It isn’t. MTProto is a protocol, not a routing mechanism. Running Telegram over a VPN sends MTProto packets through an encrypted tunnel, but those are two separate layers doing entirely separate jobs. The VPN wraps MTProto traffic in another encryption envelope and forwards it through a different exit IP. MTProto itself has no concept of routing your connection through an intermediary. When people mention “Telegram proxy,” they usually mean MTProto Proxy, a specific Telegram-designed relay extension that lets users connect through a community-run server. That’s different from a VPN, and both are different from the MTProto protocol itself. Confusing these three things leads operators to misconfigure their setups in ways that introduce ban risk or connectivity failures.

Switching IPs mid-session breaks your MTProto session. Mostly false, but the nuance matters. MTProto sessions are keyed to the authorization key, not the source IP address. In principle, an IP change does not terminate the session. In practice, Telegram’s server-side heuristics monitor for IP transitions on active sessions, particularly transitions that cross ASN boundaries or jump between countries. An account that was connecting from a Philippine residential IP and suddenly appears on a German data center IP faces a higher probability of triggering a security review than one that maintains a stable, consistent network identity. The protocol permits the change. Telegram’s fraud detection may not let it pass quietly.

MTProto’s obfuscation makes Telegram impossible to block. Censorship is an arms race, and protocol obfuscation is one tool in it, not a solution. Obfuscated MTProto makes DPI-based identification harder, but it doesn’t defeat all analysis. China’s Great Firewall has a documented history of learning to fingerprint traffic that was initially opaque. Research on active probing techniques shows that sophisticated censors can send synthetic connection attempts to suspected proxies or clients and observe the response patterns to confirm protocol identity without ever decoding the encrypted content. IP-level blocking remains the bluntest and most effective instrument, and obfuscation does nothing to hide the IP itself. When Iran or Russia decides to block Telegram at the address level, the protocol design becomes secondary.

a quick worked example

Here’s a practical check you’d actually run to understand what network your Telegram client is appearing on, and how that looks to external observers using the same tools Telegram’s trust systems implicitly reference.

# Resolve Telegram's primary datacenter hostname
dig +short dc1.telegram.org

# Check ASN and carrier metadata for that IP
curl -s https://ipinfo.io/149.154.167.51 \
  | jq '{ip, org, country, city}'

# Compare with the metadata for a real mobile carrier IP
# Replace with the actual IP from your SIM-based session
curl -s https://ipinfo.io/YOUR_MOBILE_IP \
  | jq '{ip, org, country, city}'

The output for Telegram’s DC1 will show an ASN associated with a data center operator. The output for a real SingTel SIM will show AS9506 or a similar mobile carrier ASN, tagged as a Singaporean mobile network. Both connections speak valid MTProto 2.0 to Telegram’s servers. The protocol layer is identical. But the IP reputation layer, which Telegram’s trust scoring consults alongside the protocol signals, sees entirely different profiles. This gap is exactly what dedicated vs shared mobile IPs describes at the infrastructure level: the protocol is a constant, and the network identity is the variable that separates stable accounts from flagged ones.

how telegramvault relates

TelegramVault runs your Telegram session on a physical Android handset in a Singapore server room, connected to a real SIM card on SingTel, M1, StarHub, or Vivifi. The MTProto connection your account makes to Telegram’s data centers originates from a genuine mobile carrier IP, the kind that matches the expected behavioral profile of a real user on a real device in a real country. The protocol is unmodified. The Android client speaks standard MTProto 2.0 the same way any other Android handset does. What changes is the network context around that protocol. When you join the TelegramVault waitlist, onboarding is concierge-style: you log in once with your own number and handle your own OTP. After that, the session runs continuously on the same hardware and the same pinned IP. MTProto session continuity holds without IP rotation, data center hops, or the network inconsistency that Telegram’s fraud detection is trained to catch. The protocol behaves correctly because the environment is correct. That’s the whole product in one sentence.

final word

MTProto is not magic. It is a well-engineered, purpose-built protocol that gives Telegram control over its transport layer, makes passive DPI harder to execute reliably, and keeps mobile connections alive under the kind of adverse network conditions most of its users actually face. For operators, the protocol is a stable constant. The problems almost always come from the IP, the device fingerprint, or the session history riding on top of it. Get those three right and MTProto handles itself.

What Is MTProto? Telegram's Custom Protocol Explained 2026