ton development services: Building Jetton Tokens and Onchain Marketplaces on TON

7Block Labs helps startups and enterprises ship production-grade Jetton tokens and on-chain marketplaces on TON—using the latest standards (TEP-74/64/89, Mintless Jettons, Wallet V5), shard-aware architectures, and audited tooling to reach Telegram-scale users without sacrificing security or UX. Below is our concrete playbook with patterns, pitfalls, and implementation checklists you can apply immediately. (docs.ton.org)

Summary

A hands-on guide to designing, launching, and scaling Jetton-based products and marketplaces on TON with shard-aware contract layouts, Wallet V5 gasless flows, decimals-safe transfers, and production monitoring via TonAPI—plus build-time tooling and security guardrails.

Why TON in 2025: concrete advantages that matter for decision‑makers

Shard-first architecture designed to parallelize account activity at scale; contracts can be deliberately placed “close to” users to reduce cross-shard latency for hot paths. Typical cross-shard hops add ~12–13 seconds—architect to minimize them. (docs.ton.org)
Jettons (TEP‑74) use a distributed model—each holder has their own wallet contract—removing single-contract bottlenecks and unlocking near-linear scaling with your user base. (docs.ton.org)
Wallet V5 introduces signed internal messages and gasless patterns, enabling UX such as “pay fees in USDT,” multi-send (up to 255 messages), and delegated actions—critical for mainstream apps. (docs.ton.org)
TON Connect is the standard wallet bridge for dApps and Telegram Mini Apps; SDKs exist in JS, Dart, Python, and more, accelerating client delivery. (docs.ton.org)

Jettons, precisely: the standards you’ll actually use

TEP‑74: fungible token interface (master + per‑holder wallet).
TEP‑64: metadata scheme (on‑chain, semi‑chain, off‑chain), including decimals.
TEP‑89: wallet discovery (how apps/wallets find the per‑user Jetton wallet). (docs.ton.org)

Key implications for your build:

Each user interaction hits their Jetton wallet contract, not a global ledger—so your throughput scales with users.
Decimals live in metadata. Many Jettons default to 9 decimals; USDT on TON uses 6. Treat display_amount × 10^decimals as the on-chain amount—get this wrong and you’ll send 1000× by mistake. (docs.ton.org)

Picking the right Jetton implementation in 2025

Jetton 2.0 (recommended): optimized wallet placement in the same shard as the owner’s wallet, improving latency and lowering forward fees on hot paths. (docs.ton.org)
Mintless Jetton (TEP‑177 + TEP‑176 API): for Merkle‑proof airdrops to millions—mints “on demand” in the recipient’s wallet, removing minter bottlenecks and chain load during distribution. (github.com)
Stablecoin/governance variant: reference contracts for a centralized stablecoin with admin controls exist and are TEP‑74/89 compatible—useful for compliance‑driven tokens. (github.com)

Decision tip: We ship Jetton 2.0 for most projects, layer TEP‑177 if you need viral airdrops, and reserve governance controls (freeze/blacklist/mint caps) for regulated assets.

Architecture that scales: shard‑aware Jettons

Place Jetton Wallets “close to” the owner’s Toncoin wallet. New toolchains let you set toShard: { closeTo, fixedPrefixLength } when deploying, aligning addresses into the same shard. Start at 8 bits of prefix for a good balance of control vs. brute‑force. (beta-docs.ton.org)
Why it matters: cross‑shard delivery requires a MasterChain checkpoint; expect ~12–13s additional latency per hop. Keep critical flows intra‑shard. (docs.ton.org)

Shard checklist

Partition “single points” (e.g., distributors) into many child contracts.
Avoid long synchronous chains across shards for user actions.
Precompute shard placement in tests to verify desired prefixes.

Metadata that won’t bite later: TEP‑64 in practice

Use semi‑chain metadata: put name/symbol/decimals on‑chain, large assets off‑chain via TON Storage. This keeps storage fees predictable while ensuring core fields are queryable on‑chain. (docs.ton.org)
Document decimals decisions (e.g., 6 for fiat‑like, 9 for TON‑like). Wallets read decimals from metadata; don’t hardcode in apps. (docs.ton.org)
Encode long strings/JSON with Snake data; budget bits/cells now to estimate storage fees. (docs.ton.org)

Transfers that always settle: decimals‑safe and comment‑aware

Programmatic transfer: set forward_ton_amount to allow the receiving Jetton wallet to process the forwarded message, and include comments in forward_payload if needed. Always fetch decimals before constructing the amount. (docs.ton.org)
UX gotcha: USDT uses 6 decimals; adapt your calculators and admin panels accordingly, and test on testnet with tiny amounts before mainnet. (docs.ton.org)

Distribution at scale: two battle‑tested patterns

Merkle claim (Mintless Jetton TEP‑177)

Store a single Merkle root on‑chain; users claim to mint into their Jetton wallet. Efficient for 1M+ recipients. (github.com)

Console‑managed claim airdrops

Use Ton Console’s Airdrop stack; upload CSV recipient,amount (minimal units), enforce decimals (e.g., 1 USDT → 1,000,000). Recipients pay a small TON fee to claim; your dApp integrates via TON Connect. (docs.tonapi.io)

Wallet integration: TON Connect and Wallet V5 for enterprise UX

TON Connect is the mandatory connection protocol for Telegram Mini Apps; integrate via @tonconnect/sdk (JS) or Dart/Python SDKs for Flutter/backend usage. Host your manifest and list supported wallets; use a hosted bridge or run your own. (docs.ton.org)
Wallet V5 enables gasless UX: sign an internal message containing two Jetton transfers—one to recipient, one to the relayer—and let a service (e.g., TonAPI backend) pay network fees in TON. Great for “pay fees in USDT.” (docs.ton.org)

Implementation notes

Manage seqno races for gasless relays; blacklist stuck or conflicting requests per the V5 repo guidance.
Offer user‑selectable fee tokens and fallback to native TON if the Jetton balance is insufficient. (github.com)

Building a marketplace on TON: patterns that work

A minimal, resilient marketplace = off‑chain indexer + on‑chain listing contracts + royalty compliance + Jetton payments.

What to reuse

Getgems’ open contracts demonstrate fixed‑price and auction patterns with royalties; they publish code hashes for supported sale versions and a 5% marketplace fee example—useful for compatibility testing. (github.com)
Getgems supports listing and purchasing NFTs in Jettons (e.g., USDT/NOT)—proof that Jetton‑denominated sales are production‑ready. (getgems.helpscoutdocs.com)

7Block Labs marketplace blueprint

Per‑listing sale contract: the seller transfers the NFT to a sale contract that escrows the item and enforces price, currency (Jetton master address), royalties (TEP‑66), and marketplace fees. This isolates risk per listing and shards naturally. (docs.ton.org)
Jetton support: whitelist accepted Jettons (masters), read decimals from metadata, and require the buyer’s Jetton wallet to forward a comment/receipt to the sale contract for accounting. (docs.ton.org)
Auction mode: follow the auction contract structure; keep bid increments and end‑time logic stateless in the item’s sale contract to avoid centralized coordination. (github.com)

Operational reality

Index via TonAPI’s Events/Jettons endpoints, but never build business logic on Events (they can change); rely on traces and contract state instead. (docs.tonapi.io)
For USDT‑priced listings: normalize amounts to 6 decimals and build price inputs with a decimals‑aware component to prevent admin errors. (docs.ton.org)

Fees, reserves, and storage: avoid “dead account” surprises

Total fee = storage + in_fwd + compute + action + out_fwd. Storage is continuous rent on bits/cells; deduplication of identical cells reduces costs for shared structures. (beta-docs.ton.org)
Always reserve for multi‑year storage in every contract, and compute the bound using your max cells/bits (measured in tests). Hardcode max sizes, not fee amounts; adjust per masterchain/basechain. (docs.ton.org)

Practical defaults we use

5–10 years of storage budget in each deployed contract.
Unit tests that stuff worst‑case metadata into state and assert reserve calculations. (docs.ton.org)

Message safety: bounce rules and send modes you must honor

Internal messages should be bounceable by default; implement onBounced handlers and never execute the original body from a bounced payload. Consider “RichBounce” only when you need full body and exit codes; default to cheaper 256‑bit bounce data. (docs.ton.org)
Understand send modes (who pays forward fees, rollback behavior) and document them in your review checklist—misusing modes can cause silent burns or missed bounces. (docs.ton.org)

Security hardening: TON‑specific traps and patterns

Replay protection on external entries; reject stale seqno.
Never accept external messages unconditionally; spend gas_credit only after checks.
Pre‑budget gas and reject too‑low message.value early.
Keep admin upgradability explicit; TON supports setcode—gate updates and emit proofs.
Don’t leak secrets on‑chain; emulate shows everything. (docs.ton.org)

Tact/Tolk resources

Tact has a Trail of Bits audit and a growing ecosystem; follow its security guide. Tolk is the official language going forward; both fit well with Blueprint. (docs.ton.org)

Tooling that speeds teams up (and reduces regressions)

Blueprint: scaffold, compile (Tolk/FunC/Tact), test with @ton/sandbox, deploy with TON Connect. Start with npm create ton@latest, then blueprint build/test/run. (docs.ton.org)
Sandbox network for integration tests against realistic APIs. (tondev.org)
TonAPI: balances, holders, actions, emulation; embed their Events with the explicit “UI only” warning. (docs.tonapi.io)
Assets SDK and Wallet V5 wrappers to wire transfers and sales fast. (docs.ton.org)

Example: a Jetton + marketplace MVP that ships in 6–8 weeks

Week 1–2: Token spec + governance

Choose Jetton 2.0, set decimals, mint caps, admin powers; prepare semi‑chain metadata.
Decide accepted currencies for marketplace (e.g., USDT and TON). (docs.ton.org)

Week 2–3: Contracts

Implement Jetton master/wallet with shard‑aware placement.
Fork sale contracts (fixed‑price first) with Jetton whitelist, TEP‑66 royalties, marketplace fee. (beta-docs.ton.org)

Week 3–4: Client + wallet

Integrate TON Connect; add decimals‑safe inputs; implement Wallet V5 gasless option for USDT. (github.com)

Week 4–5: Indexer + ops

Index with TonAPI; implement traces-based settlement checks; alerts on bounce or short reserves. (docs.tonapi.io)

Week 5–6: Security + test

Unit tests in Sandbox, storage reserve tests, bounced‑message tests, send‑mode coverage.
Third‑party review; enable static analyzers (Misti, TSA). (docs.ton.org)

Optional: Mintless airdrop module for growth, or an auction flow via Getgems’ patterns. (github.com)

7Block Labs delivery approach

Product first: tokenomics/UX reviews before code.
Shard-aware design reviews for hot paths (buys, bids, claims).
Security gate: replay protection, bounced paths, storage reserves, upgrade keys, decimals checks.
Observability: traces-based settlement, balances reconcilers, fail-safes for relay gasless sends.
Documentation: manifest for TON Connect, decimals policy, accepted Jettons, send modes, and emergency runbooks.

If you’re exploring TON for consumer-scale apps or embedded Telegram flows, we can take you from whiteboard to audited mainnet in weeks—not months.

Reference links used in this guide

Jettons overview (TEP‑74) and distributed architecture; Jetton comparison and Jetton 2.0. (docs.ton.org)
Token metadata (TEP‑64) with decimals and Snake encoding. (docs.ton.org)
Transfer mechanics: forward_payload, forward_ton_amount, decimals risk; code wrapper example. (docs.ton.org)
Mintless Jetton (TEP‑177/176) reference implementation. (github.com)
Wallet V5 (gasless, multi‑send, API) and repo. (docs.ton.org)
TON Connect overview and SDKs. (docs.ton.org)
Sharding—latency of cross‑shard hops; deploy “close to” another contract. (docs.ton.org)
Fees: breakdown + storage fee formula and deduplication; reserve patterns. (beta-docs.ton.org)
Marketplace contracts and Jetton sales (Getgems), royalty ref (TEP‑66 via NFT reference). (github.com)
Airdrop via Ton Console (CSV format, decimals=6 for USDT). (docs.tonapi.io)
Security best practices for TON and Tact. (docs.ton.org)
Tact language: adoption, audit; Blueprint + Sandbox tooling. (docs.ton.org)

Brief in‑depth details (TL;DR for engineers)

Always fetch decimals from metadata before computing amounts; cache per Jetton master with TTL. (docs.ton.org)
For USDT pricing, normalize to 10^6 everywhere (UI, server, contracts); add unit tests that fail if a token’s decimals ≠ expected. (docs.ton.org)
Use Wallet V5 internal_signed + relay for gasless; protect against seqno races; quarantine conflicting signatures server‑side. (docs.ton.org)
Set toShard closeTo buyer/seller wallets for sale contracts that receive funds frequently. Start with fixedPrefixLength=8—measure hops in staging. (beta-docs.ton.org)
Reserve 5–10 years of storage using measured max bits/cells; assert reserves in tests. (docs.ton.org)
Default to bounceable internal messages; implement onBounced with cheap 256‑bit bodies; only switch to rich bounce when you need exit codes. (docs.ton.org)

7Block Labs can implement, audit, and operate all of the above for your token and marketplace stack.