TEP (TON Enhancement Proposal)

A TEP — TON Enhancement Proposal — is the formal mechanism by which changes to the TON protocol and ecosystem standards are proposed, discussed, and adopted. It mirrors Ethereum’s EIP system: a numbered, versioned document describing what the proposal does, why, and how compatibility is preserved.

The TEP repository lives at github.com/ton-blockchain/TEPs and is the canonical source for all standards.

What a TEP looks like

A typical TEP is a Markdown document with these sections:

• Title and number.
• Authors.
• Status — Proposed, Active, Partially Deployed, Deployed, or Withdrawn.
• Motivation — what problem this solves.
• Specification — the technical details, often including TL-B schemas and contract interfaces.
• Rationale — why this design over alternatives.
• Reference implementation — a link to a working contract or library.

The structure is described in TEP-1, which is the meta-proposal explaining the proposal lifecycle itself.

How a proposal moves through the process

1. Discuss. An idea is floated in the TON developer chat, on social media, or as an issue on the TEPs repo.
2. Draft. A TEP author copies the template, fills it in, and opens a pull request.
3. Review. Other developers, foundation members, and ecosystem maintainers comment. Specifications are refined.
4. Acceptance. Once enough actors agree, the TEP is merged with status “Proposed” or “Active”.
5. Deployment. Wallet teams, DEXes, indexers ship the change. As more parties adopt it, status moves through “Partially Deployed” to “Deployed”.

There is no on-chain governance vote for non-protocol TEPs; adoption is by community consensus and shipping software. Protocol-level changes (gas pricing, validator parameters) require validator vote on the masterchain.

Notable TEPs every TON developer should know

• TEP-62 — NFT Standard. Defines the contract interface for non-fungible tokens (collection contract + per-item contract). Without TEP-62, every NFT marketplace would need bespoke integration per project.
• TEP-66 — NFT Royalty Extension. Adds a royalty record to TEP-62 collections so marketplaces can deduct artist royalties on secondary sales.
• TEP-74 — Jetton (Fungible Token) Standard. The jetton interface — master contract, per-holder wallet contract, transfer/internal-transfer flow. This is the standard underlying USDT (TON), NOT, DOGS, and every other jetton.
• TEP-89 — Discoverable Jetton Wallets. Lets a user’s jetton wallet address be derived deterministically without an external lookup, simplifying receive flows.
• TEP-81 — DNS NFT. The standard that makes .ton domains transferable as NFTs.
• TEP-64 — Token Data Standard. Off-chain metadata schema (JSON) for jettons and NFTs.
• TEP-1 — Proposal lifecycle. The meta-spec.

Why TEPs matter

Without standards, every wallet would speak its own jetton dialect; every DEX would have to integrate every NFT collection separately. TEPs are the social technology that makes the TON ecosystem composable: any wallet that implements TEP-74 correctly can hold any TEP-74 jetton, today and in the future.

Practical notes

• Read the full TEP before integrating. “Mostly compatible” is a common source of bugs (e.g. ignoring the forward_payload in TEP-74 transfers).
• Track status. A TEP marked “Proposed” is not yet a stable target — building on it risks breakage if the spec changes.
• Reference implementations are the source of truth in practice. Production wallets and DEXes follow the canonical contract code more closely than the prose of the spec.