Crypto_Vazima

A practical way to separate the real STON.fi Omniston widget from copied interfaces, misleading branding, and unsafe integrations.
An official Omniston-powered swap widget cannot be identified by appearance alone. The STON.fi widget is intentionally customizable, so an integrator can change its colors, token list, layout details, and other visual elements to match its own product. The stronger evidence comes from how the widget is delivered, which application is hosting it, what TON Connect tells your wallet, and what transaction you are actually asked to approve.
That distinction matters because an authentic STON.fi widget may look very different from STON.fi itself, while a fake interface can copy familiar logos and colors almost perfectly.
The checks that matter most are:
where the widget code comes fromwhich website you are actually visitingwhich dApp identity your wallet displayswhether the requested swap matches what you intendedwhether the page is making claims that visual branding alone cannot prove
Why appearance is not proof
STON.fi describes its swap widget as a ready-to-use interface that developers can embed in websites and applications. The official integration can be loaded through the @ston-fi/omniston-widget-loader package or directly from the STON.fi CDN. Both methods expose the same OmnistonWidget constructor.
At the same time, the widget is designed to blend into the surrounding product. Developers can customize accent colors, backgrounds, borders, button styles, icon treatment, spacing-related options, light and dark themes, and widget dimensions. They can also control which assets appear and preselect a trading pair.
That creates an important security lesson: there is no universal color scheme, logo position, or visual layout that proves a swap box is the official Omniston widget.
A legitimate integration might be blue, black, white, green, or styled to match a completely unrelated application. Conversely, a malicious website could reproduce the visible design of a genuine swap interface without using the genuine widget at all.
Even a label such as "Powered by STON.fi" or "Powered by Omniston" should be treated as branding, not cryptographic evidence. Text and logos are among the easiest parts of an interface to copy.
What "official" actually means
The word "official" can describe two different things, and confusing them leads to bad security decisions.
The first is official widget code. STON.fi distributes its current widget as a CDN-hosted bundle. The documented CDN path uses the widget.ston.fi domain, with major-version paths such as /v0/. STON.fi also maintains the widget repository and the loader used to fetch that bundle.
The second is an official website or trusted integrator. A third-party project can legitimately embed the official STON.fi widget on its own domain. That does not turn the entire website into an official STON.fi property. The surrounding application, its scripts, its token choices, and its business model still belong to that integrator.
This difference is essential.
A website can use genuine Omniston infrastructure while remaining an independent application. Likewise, seeing an official STON.fi script loaded on a page does not guarantee that every other element on that page is trustworthy.
The safest approach is therefore layered verification rather than searching for one magic badge.
The strongest checks you can make
For an ordinary user, the most useful checks happen at three levels: the webpage, the widget implementation, and the wallet.
1. Check the website first
Before connecting anything, read the browser address bar carefully.
If you intentionally opened STON.fi, make sure you are actually on the expected STON.fi property. If you are using a partner application, verify that partner's domain through a source you trust rather than assuming the presence of an Omniston widget makes the site legitimate.
A genuine widget is allowed to live on a third-party domain. That is normal. What matters is that you know which third party you are trusting.
Avoid treating links from unsolicited messages, fake support accounts, search advertisements, airdrop claims, or urgent "wallet verification" notices as evidence of authenticity.
2. Check where the widget code comes from
STON.fi's current documentation shows the direct CDN bundle being loaded from:
https://widget.ston.fi/v0/index.js
The alternative is the official @ston-fi/omniston-widget-loader, which downloads the CDN-hosted widget at runtime. STON.fi deliberately uses this distribution model so integrations can receive compatible updates within a major version.
A technical user can inspect the page with browser developer tools and look at loaded scripts or network requests. Finding the documented STON.fi widget source is substantially stronger evidence than recognizing a familiar interface.
It is still not sufficient on its own. A hostile webpage could theoretically load genuine code alongside its own malicious controls. The page itself must still be trusted.
3. Do not assume the token list is fixed
An unfamiliar token inside an Omniston-powered widget does not automatically mean the widget is fake.
STON.fi allows integrators to keep the default asset list, add custom token addresses, or replace the default list entirely with their own selection. Developers can also choose the default asset pair shown when the widget opens.
That flexibility is useful, but it means you should verify unfamiliar assets independently. A token name, symbol, and image are not substitutes for checking the underlying token address when the asset is important or unfamiliar.
4. Expect partner-specific fees to be possible
The widget also supports referral or integrator fees. Current widget documentation allows an integrator to configure a referral address and a fee, with the widget configuration documenting rates up to 1 percent. Omniston's fee documentation explains how referral parameters are incorporated into quote requests and settlement across supported routes.
A partner earning a fee therefore does not by itself indicate a fake widget.
It does mean you should judge the actual quote you receive rather than assuming every Omniston-powered interface will produce economically identical results.
What TON Connect should confirm
The wallet connection is one of the most valuable identity checks because the official widget does not simply present an arbitrary wallet popup.
STON.fi requires the integrator to provide a TON Connect configuration. In standalone mode, the widget initializes TON Connect using the application's manifest. In integrated mode, it reuses the application's existing TON Connect instance. STON.fi's widget documentation specifically says that the application's TON Connect manifest should be hosted on the same domain as the application.
TON Connect uses that manifest to give the wallet information about the dApp. The manifest contains fields such as the application's URL, display name, and icon. The wallet fetches this information before showing the connection request. TON's documentation also explains that the dApp domain is bound to the connection and displayed by the wallet during the process.
This creates a useful check.
If you are on example.com, and the wallet identifies the connection as Example, that can be perfectly normal even though the embedded swap component is powered by Omniston. You should not necessarily expect the wallet to say STON.fi. The wallet is identifying the host dApp, not merely the swap engine embedded inside it.
What should concern you is inconsistency.
For example:
You open one domain.You press Connect Wallet.Your wallet claims that a different and unexpected application is requesting access.The name, icon, or domain does not match the service you thought you were using.
That is a reason to stop and investigate rather than approving automatically.
TON Connect also does not remove the need to review transactions. Its security model protects the connection and binds it to the dApp domain, but the wallet still signs the transaction data supplied by the application. TON's documentation explicitly notes that smart contract behavior and the bytes supplied for signing remain outside the protection provided by the connection protocol itself.
Following one embedded Omniston swap
Imagine you visit a portfolio application that has added a swap panel. The interface uses the application's own colors, has no large STON.fi logo, and offers a custom selection of tokens.
None of those details prove that it is fake.
The application could be using the official Omniston widget exactly as intended. STON.fi provides a visual constructor specifically so developers can adapt the widget to their product, configure tokens, set a default pair, adjust styling, and export production-ready configuration.
You decide to verify the integration instead of judging the design.
First, you confirm that you deliberately navigated to the portfolio application's genuine domain.
Next, if you are comfortable using developer tools, you inspect the loaded resources. You find the widget bundle coming from the documented STON.fi widget domain. That tells you the embedded component is using STON.fi's distributed widget rather than merely copying its appearance.
Then you press Connect Wallet.
Your wallet displays the portfolio application's identity, not STON.fi. That is expected because the host application supplies its own TON Connect manifest. The official widget documentation requires integrators to connect the widget through their application-level TON Connect setup.
You choose the assets and request the trade. Behind the interface, Omniston is the liquidity aggregation layer. STON.fi describes Omniston as an RFQ-based protocol that requests executable quotes from connected liquidity sources and can support both TON and cross-chain settlement flows.
Finally, the wallet presents the action for approval.
At this point, recognition becomes transaction verification. Check that the action is consistent with the swap you just requested. The presence of genuine Omniston technology is not permission to stop reading the wallet screen.
This example also explains why authenticity is not binary. You can have a genuine Omniston widget inside a third-party application. You are trusting both layers for different reasons.
Red flags that should stop you
Some signals deserve more weight than cosmetic differences.
Be especially cautious when:
the website claims to be STON.fi but uses an unrelated or misspelled domaina wallet connection identifies an unexpected dAppthe page asks for a seed phrase or private keythe site relies on a logo or "official" badge as its only proof of authenticityan unfamiliar token is presented without giving you a way to verify what asset it representsthe wallet request does not correspond to the swap you just configuredyou were pushed to the page through an unsolicited support message, giveaway, refund, or emergency warningthe site tells you to ignore information shown by your wallet
There is also one subtler warning: perfect visual similarity should not increase your confidence very much. A phishing page can reproduce screenshots and styling. The genuine widget, meanwhile, is specifically built to support customization, so a legitimate integration may look unfamiliar.
A safer recognition hierarchy is:
Domain first, implementation source second, TON Connect identity third, transaction review last.
Each layer answers a different question. Together they provide much stronger evidence than branding.
Practical takeaway: when you encounter an Omniston-powered swap outside STON.fi, do not ask only, "Does this look official?" Ask four separate questions: "Do I trust this host domain?", "Is it actually loading the documented STON.fi widget?", "Does my wallet identify the dApp I expected?", and "Does the transaction match the swap I intended?" If any answer is unclear, you do not need to sign.
Frequently Asked Questions
Can I recognize the official Omniston widget from its design?
No. STON.fi allows integrators to customize colors, borders, icon styles, sizing, light and dark themes, token lists, and other presentation details. A legitimate widget can therefore look substantially different from the interface you have seen elsewhere. Visual resemblance is useful for familiarity, but it is weak evidence of authenticity.
Does an official widget always appear on a STON.fi domain?
No. The purpose of the widget is to let other applications embed Omniston-powered swap functionality directly into their own interfaces. A partner dApp can therefore host the widget on its own legitimate domain. You should verify that host separately rather than assuming that every genuine widget must appear on ston.fi.
Does "Powered by Omniston" prove that a swap interface is genuine?
No. Anyone can reproduce a piece of text or a logo. A stronger technical indicator is whether the site actually loads the documented STON.fi widget bundle or uses the official loader. Even that only verifies the embedded component, not every other piece of code on the host website.
Why does my wallet show the partner application's name instead of STON.fi?
Because TON Connect identifies the dApp requesting the connection. STON.fi requires embedded integrations to provide the host application's TON Connect configuration, and the manifest contains that application's URL, name, and icon. Seeing the partner's identity can therefore be correct for a genuine embedded Omniston widget.
Can a genuine Omniston widget show custom tokens?
Yes. Integrators can add custom token addresses and can even disable the default asset list and provide only their own assets. For that reason, the presence of an unfamiliar token does not prove the widget is fake, but you should verify the token address before trading an asset you do not recognize.
Can an Omniston widget charge an integrator fee?
Yes. STON.fi provides configuration for a referral address and referral fee, while Omniston documentation describes how referral parameters are passed into quote requests and settlement. Fees are therefore a supported integration feature rather than automatic evidence of tampering.
If the widget code is official, is the entire website safe?
No. Loading STON.fi's genuine widget proves something about that component, not the entire host application. Other scripts, navigation elements, token promotions, or transaction flows can still belong to the integrator. You should independently verify the host domain and inspect every wallet request before approving it.
What is the best way to verify an Omniston-powered widget before swapping?
Start with the website domain. If you need stronger confirmation, check whether the implementation uses STON.fi's documented widget distribution. Then connect your wallet and verify that TON Connect identifies the dApp you expected. Finally, compare the wallet transaction with the assets, amount, and action you actually requested. Never let an "official" label replace those checks.
Sources and Further Reading
STON.fi Widget - official overview of the embeddable swap widget, CDN integration, customization, TON Connect modes, and configurationSTON.fi Full Guide & Reference - detailed reference for the Omniston widget loader, CDN bundle, custom assets, referral settings, theming, and lifecycle behaviorSTON.fi Omniston Protocol - official overview of Omniston liquidity aggregation, RFQ routing, supported chains, and integration approachesSTON.fi Referral Fees - technical documentation for Omniston referral parameters and fee settlementSTON.fi Omniston Widget GitHub repository - official source repository and documented CDN distribution modelTON Connect Core Concepts - official TON documentation covering manifests, dApp identity, domain binding, and the security modelTON Connect Get Started - official guide to the manifest fields, hosting requirements, and wallet connection flow
$BTC $GRAM