Two names, one thing
This is worth clearing up first, because right now it's the single most confusing live fact about the network Zyrvix runs on. TON β The Open Network β is the blockchain itself: the public ledger, the validators, the address format, the whole chain-level infrastructure. That hasn't changed and isn't changing. What changed is the name of the coin that runs on it. On June 15, 2026, following a community governance vote that concluded on June 8 with 81.22% approval, the native coin was renamed from Toncoin (TON) to Gram (GRAM) β the original name the project used before Toncoin. Ecosystem-wide consistency across exchanges, wallets, and explorers was targeted for June 22. Nothing about how the coin works changed: same balances, same addresses, same wallets, no migration, nothing to move. Only the label did.
So: TON is the network, Gram is what its native coin is called now. You'll see both names for a while, on Zyrvix and everywhere else in the ecosystem, because a ticker rename this size doesn't land everywhere on the same day β or even everywhere on the same page. In the interest of not making you find this out the awkward way β by noticing a mismatch yourself β here's where Zyrvix's own interface actually stands as of this writing, surface by surface.
- The payer-facing explainer is the one place that's genuinely gone Gram-forward: its hero, its "What is GRAM?" section, and its wallet guidance all use the new name, with "TON" showing up only where it's explicitly explaining that the two names mean the same coin.
- The landing page's hero headline says "Accept crypto payments in GRAM," but that's currently the only line on that page that does β the hero's body copy, the features section, and the page's own title and description still say "TON."
- The hosted pay page takes a third shape: it shows the amount due as "TON," with "(GRAM)" next to it in smaller text as a disambiguator, and its network label still reads "TON Mainnet," no Gram mentioned there at all.
- The pricing page and the dashboard haven't been touched yet and are TON throughout.
None of that is a typo and it's not two different products β it's one rename in progress, landing unevenly across the interface rather than page by page. If you're reading this and the rest of the product has caught up by the time you check, good; if you spot the seam in the meantime, this is that seam, named honestly rather than left for you to puzzle out.
What "runs on TON only" actually means for Zyrvix
Zyrvix operates on exactly one chain: The Open Network. Not TON-and-a-few-others, not "TON plus whatever we bridge in later" β one chain, full stop, independent of whatever its native coin happens to be branded this year. That's a scope decision about the chain, not a statement about a ticker, and the rebrand above doesn't touch it at all.
There's a real reason a payments product benefits from staying narrow here. One chain means one settlement asset, which means one matching pipeline β a native transfer plus a memo, watched by a single scanner, with no branching logic for "which network did this come in on." It means amount semantics that are unambiguous everywhere in the system, a fee model denominated end-to-end in the same unit as the payment itself, and a non-custodial correctness story simple enough to actually verify β the kind of claim you can check on a block explorer yourself instead of taking on faith. For a gateway whose entire pitch is "trust the mechanism, not the company," a small, auditable surface isn't a limitation to apologize for β it's the feature.
The question we actually get: can my customers pay in USDT on TON?
This is the most common question Zyrvix hears from merchants evaluating the product, and it deserves a straight answer rather than a roadmap dodge: not today. What follows is the real reasoning behind that, not a placeholder for "we'll get to it."
What USDT-on-TON actually is, technically
It's worth being precise about what's actually being asked for, because it's easy to lump it in with "just support more coins" β and it isn't that. USDT on TON is a Jetton: a token standard native to The Open Network, not a wrapped asset bridged in from somewhere else. A Jetton transfer still moves between ordinary TON wallet addresses, still carries a comment field the same way a native transfer does, and shows up on-chain as a transfer-notification message a scanner can watch for β the same shape of problem Zyrvix already solves for native TON, with a different message format to parse. That's exactly why it's a fair, well-posed question and not a category error like asking a TON-only gateway to support an entirely separate chain: Jettons are genuinely compatible with the same wallet-to-wallet, non-custodial design this product is built around, not an architectural stretch.
Why merchants ask
The demand behind this question is real and deserves to be taken at face value rather than minimized. Getting paid in a native coin means every sale carries that coin's price movement between the moment a customer pays and the moment a merchant decides what to do with the balance β and for a business trying to price goods or services predictably, that volatility is a genuine cost, not a hypothetical one. Stablecoin settlement removes that exposure entirely: what lands in the wallet is worth the same tomorrow as it was today. USDT is arguably the dominant settlement asset in TON-ecosystem commerce for exactly this reason, and a merchant who wants that property isn't asking for something exotic β they're asking for the standard the rest of the ecosystem already leans on.
Where Zyrvix stands
Jetton support β including USDT on TON β is on the radar as a post-launch candidate. It is not built, not scheduled, and has no date attached to it. It will only ship if it can be built without giving up the property this entire product is built around: wallet-to-wallet settlement, with Zyrvix never taking custody of a payment at any point. If that condition can be met, it becomes a real possibility; until it's actually built, the honest status is "under consideration," not "coming soon."
Operating on TON/Gram today
None of the above means volatility exposure is left unmanaged in the meantime β it's just handled differently than a stablecoin would handle it. Three things do most of the work. First, invoice expiry windows are short, measured in minutes rather than hours or days, which bounds how much the market can move between an invoice being created and it either being paid or expiring. Second, every invoice is priced in the native coin at the moment it's created, not re-priced later, so there's a single, unambiguous amount the payer is asked for from start to finish. Third, the audience this product actually serves β crypto-native operators who already hold TON for gas and transaction fees as a matter of course β isn't being asked to newly tolerate volatility exposure as a condition of using a crypto-native product; it's already part of how that audience operates day to day.
Put together, that's the real, current answer to "why TON-only": not a permanent ceiling, not a promise of what's next, just where the product genuinely stands today β and how it manages the one tradeoff that comes with standing there. For the mechanics of how a payment gets matched and confirmed in the first place, see how to accept TON payments.