Create a TON Jetton: Master Address vs Holder Wallet
Create a TON Jetton with a clear distinction between the master address and each holder’s Jetton wallet. Record metadata, supply and deployment proof.
Illustration and design · SlingZero
Creating a TON Jetton produces an asset identified by its master contract; a holder’s Jetton wallet has a separate address and role. Confusing those addresses can cause problems when publishing identifiers, integrating payments or investigating why a wallet balance is not appearing where someone expects it.
One asset, different address roles
The master identifies the Jetton type and its administration context. A holder's Jetton wallet is associated with that holder and the Jetton. Those roles should be labeled explicitly in an operating record rather than collected under one ambiguous “token address” heading.
The TON Jetton processing documentation describes this architecture and why address validation matters. This article introduces the distinction for creators; a payment integration still needs its own verification and processing design.
Concept illustration — The asset's master contract is different from a holder-specific wallet contract.
Prepare the creator's identity brief
Decide the intended name, symbol, initial supply and public metadata before deployment. Record the wallet responsible for launch and the retained administrative choices supported by the implementation.
Use a network-labeled record for any rehearsal. A test deployment and a production deployment should not share an unlabeled list of addresses, even when their branding is identical.
Inspect the actual TON creator
Open Create a TON Jetton to review the current SlingZero flow.
Connect the appropriate TON wallet, check the selected network and review the fields and controls actually offered. Read the current deployment cost and wallet request before signing. Do not assume that settings from an ERC-20 or SPL tutorial map directly to this architecture.
After confirmation, preserve the deployment evidence and the resulting identifiers. Identify which recorded address is the master and which addresses, if any, represent a holder-specific wallet or another contract involved in the operation.
Publish identifiers that a reader can use
When announcing the Jetton, label the network and master identifier clearly. If documentation also discusses a holder's Jetton wallet, explain why that address is different and how it relates to the holder.
Avoid using a logo, symbol or shortened address as the only evidence of identity. An integration accepting payments must validate more than the text a sender supplies; confusing the asset and holder-wallet roles can undermine reconciliation.
Keep deployment separate from later milestones
Creating the Jetton does not automatically establish a market, a listing or a fully tested payment system. Verify those follow-up activities independently. The creator's first deliverable is a reliable identity and deployment record—one that another operator can read without guessing which of several TON addresses represents the asset being discussed.