# WalletTg: Telegram wallet contract (https://docs.ton.org/llms/contracts/standard/wallets/telegram/overview/content.md)



WalletTg is the TON wallet contract used by the [Telegram's native Gram wallet](https://docs.ton.org/llms/onboarding/wallet-apps/telegram/content.md).

## Features [#features]

* Receive Gram, jettons, and non-fungible tokens (NFTs) at a stable address.
* Send a [single message](https://docs.ton.org/llms/contracts/standard/wallets/telegram/messages/content.md) or a [batch of up to 255 messages](https://docs.ton.org/llms/contracts/standard/wallets/telegram/messages/content.md).
* Connect to decentralized applications (dApps) through [TON Connect](https://docs.ton.org/llms/applications/ton-connect/overview/content.md).
* Import [12-word phrases or 24-word rotation mnemonics](https://docs.ton.org/llms/contracts/standard/wallets/telegram/key-management/content.md) in compatible wallet apps.
* Disable Telegram's encrypted backup, with an optional signing-key rotation.
* [Rotate the signing key](https://docs.ton.org/llms/contracts/standard/wallets/telegram/key-management/content.md) while keeping the same address.
* Submit signed internal requests through a [relayer](https://docs.ton.org/llms/contracts/standard/wallets/telegram/interact/content.md) that attaches Gram for processing.

## Shared implementation [#shared-implementation]

Each account stores immutable *trampoline* code. The trampoline loads the shared implementation from [configuration parameter `-123`](https://docs.ton.org/llms/foundations/config/content.md), while each account keeps its own balance and storage.

<Image src="/images/wallets/telegram/architecture.svg" darkSrc="/images/wallets/telegram/architecture.svg" alt="WalletTg accounts keep trampoline code and local storage while executing shared implementation code from configuration parameter minus 123." width="900" height="390" />

Validators approve configuration changes through voting. An update changes the implementation used by every WalletTg account on that network. Wallet owners cannot change the implementation or opt out of updates.

The brief [contract reference](https://docs.ton.org/llms/contracts/standard/wallets/telegram/contract/content.md) documents storage and upgrade migration behavior.

## Address anchor and signing key [#address-anchor-and-signing-key]

The contract address is derived from the original [`StateInit`](https://docs.ton.org/llms/foundations/messages/deploy/content.md), which includes the trampoline code and anchor public key.

Initially, the anchor is also the signing key. Rotation replaces the current on-chain signing key but leaves the original `StateInit` and address unchanged.

<Callout type="caution">
  Composing a new `StateInit` with the replacement key derives a different address.
</Callout>

After rotation, only the current signing key authorizes requests; the anchor cannot restore signing access. The [key-management reference](https://docs.ton.org/llms/contracts/standard/wallets/telegram/key-management/content.md) explains the two-key mnemonic and rotation.

## Backup and self-custody [#backup-and-self-custody]

Telegram's [encrypted backup and phrase updates](https://docs.ton.org/llms/contracts/standard/wallets/telegram/key-management/content.md) are app features, separate from contract storage.

## Comparison with V5 [#comparison-with-v5]

WalletTg and [wallet V5](content/contracts/standard/wallets/v5) use different signed-request encodings. That is, the layout and composition of their messages differ. Refer to the [WalletTg message reference](https://docs.ton.org/llms/contracts/standard/wallets/telegram/messages/content.md) and the [V5 reference](https://docs.ton.org/llms/contracts/standard/wallets/v5-api/content.md) for details.

<Callout type="note">
  Compare wallet capabilities in the [table](https://docs.ton.org/llms/contracts/standard/wallets/comparison/content.md).
</Callout>
