The short answer
Three address-specific facts must be read together:
get_jetton_dataliterally returnsmintable = true.- The current administrator is the workchain-0 zero address.
- The matched code requires that administrator for minting and provides no path to restore the authority.
The getter reports the implementation's hard-coded mintable flag, but admin authority was sent to the zero address. Under the verified code and state, no further UDOCAT can be minted. Holders can still burn tokens, so total supply can decrease.
Saying only “mintable” omits the operational state. Saying mintable = false contradicts the getter. Calling the supply fixed ignores holder burns.
The exact Jetton data
EQAiB6nk1U4Cej3FWGBL2rfmCKfxLFRY5_HkwcFn8y1IQeaD
The following values are from the 22 August 2026 verification snapshot. Holder burns can reduce the supply after that date.
- Raw master
0:2207a9e4d54e027a3dc558604bdab7e608a7f12c5458e7f1e4c1c167f32d4841- Atomic supply
- 10,000,000,000
- Decimals
- 4
- Display supply
- 1,000,000.0000 UDOCAT
- Literal mintable value
-1· true- Administrator
0:0000000000000000000000000000000000000000000000000000000000000000
TON's Jetton interface deliberately returns supply, mintability, administrator, content, and wallet code as separate fields. A single label cannot describe the contract's practical control state.
Official TON sources: TEP-74 master contract and supply-data guide.
Why the getter and operational state differ
The matched Jetton minter returns -1 for mintable directly. It does not recalculate that field from whether the stored administrator can still act. In the same contract, minting is accepted only when the sender equals the administrator. The zero address is now stored in that role.
Changing the administrator and changing metadata also require the current administrator. The matched master contains no code-upgrade, proxy, administrator-restoration, alternative mint-authority, or self-destruction path. The conclusion comes from the zero-admin state plus the exact deployed implementation—not from a generic rule about every Jetton.
This is an implementation and source match, not a claim of a formal third-party security audit or an on-chain source-registry attestation.
Official TON sources: matched minter implementation and administrator-revocation guidance.
What holders can still do
Normal holder activity is not frozen. Existing tokens can move between holders, and a holder can burn tokens from their own Jetton wallet. A valid burn notification reduces the master's recorded total supply.
- Further minting is operationally unavailable under the verified code and state.
- Existing tokens can still be transferred.
- Holders can reduce supply by burning their own tokens.
- The current supply is not guaranteed to remain exactly 1,000,000.0000 UDOCAT.
Official TON source: Jetton token-burning flow, the matched wallet burn code, and the matched master supply update.
What zero-admin does not prove
Zero-admin does not establish value, market quality, holder independence, or ownership of liquidity. It also does not audit an external exchange or pool. Those are separate questions.
UDOCAT's separate GRAM market is the STON.fi V2.2 pool at EQA6j5Fw4_s9kuoPcJuDsEvm8RxUwxJ7aunmKkeAiTx_LkPT. Its verified base fee split is 0.20% for liquidity providers and 0.10% for the protocol. The pool has extremely low liquidity, so any market observation needs a fresh exact-address reading and should not be interpreted as realizable value.
The useful lesson is narrow: for this Jetton, an honest answer requires the literal getter, the current administrator, and the behavior of the exact deployed code.
Official STON.fi sources: V2 pool reference and fee documentation, plus the exact pool data and its V2.2 router.