We picked up a recurring pattern in our Google Search Console data this quarter: hundreds of users typing the contract address 0xea4bc384184a5ccb02a079ea76931c57732c5de4 into Google, often with the qualifier site:gimbutiscoin.com. That is the signature of due diligence - someone received the address (from a video stream, a Discord, a sales pitch) and wants to verify it is actually associated with the official project before sending any money.
Here is what those searchers find, and what they do not find.
The project: Gimbutis Coin
gimbutiscoin.com is a real, operational project. The signals we can confirm:
- Domain age: registered 2022-12-12 (3 years and 5 months at time of writing)
- Mobile apps: official iOS app and Android app under “Gimbutis X”
- Sub-app:
app.gimbutiscoin.com/sign-in(account / dashboard interface) - Live stream:
stream.gimbutisx.com(HLS video stream) - Social presence: X (@gimbutiscoin), Instagram, YouTube, Discord
- Marketing stack: Google Tag Manager (G-94MRXTR7EN), CookieYes consent banner, Next.js front-end
The pitch on the homepage: “Gimbutis Coin - Gold and Silver-Backed Tokens”. The site references two ERC-20 contract addresses inside its JavaScript bundle (/_next/static/chunks/522-88bf4ca22021b264.js):
0xea4bc384184a5ccb02a079ea76931c57732c5de4- Gimbutis Silver (GXAG)0xF92a337927fC48d7c3300ca4B7e6A7d2b6103E43- Gimbutis Gold (GXAU)
So the contracts are acknowledged by the official project. This is not a brand-jack, the way many of our scam articles describe - it is the real team’s deployment.
We pushed both addresses through our analyzer at the time of writing. The result is the most important finding of this whole article:
Both tokens - GXAG (silver) and GXAU (gold) - return the exact same 7 risk flags in our scoring engine, and the same 70/100 risk score. Both are deployed as
TransparentUpgradeableProxycontracts by the same deployer pattern.
That is not a one-off mistake. The team chose the same architecture twice, on purpose, for both their flagship products. The flags below describe a systematic design choice by Gimbutis Coin, not a misconfigured single contract.
The question shifts from “is this address fake?” to “is the underlying contract structure compatible with what a precious-metal-backed token should look like?”
The 7 on-chain risk flags
We analyzed 0xea4bc384...5de4 through our standard ERC-20 pipeline. The flags returned, and what each one means for a token whose value claims to be backed by physical silver reserves:
| Flag | What it means | Why it matters for a “backed” token |
|---|---|---|
| unrestricted_mint | The contract exposes a mint() function that can create new tokens without an explicit on-chain cap or proof-of-reserves callback | The biggest single concern. A silver-backed token should mathematically guarantee that you cannot mint more tokens than the physical silver held in custody. Without a mint cap or attestation oracle, the team can issue tokens whenever they want. |
| upgradeable_proxy | The contract is an upgradeable proxy - the implementation logic can be swapped by the owner at any time | What you audit today may not be the contract that runs tomorrow. PAXG (Paxos Gold) and XAUT (Tether Gold) are not upgradeable for exactly this reason - once a token claims metallic backing, the rules need to be set in stone. |
| hidden_owner | The owner / admin address is not the publicly-stated team address. Could be a multisig, could be a personal wallet | For an institutional-grade backed asset, ownership should be transparent (typically a published multisig or a regulated custodian’s wallet). Hidden ownership prevents anyone from checking which party can authorize a mint or an upgrade. |
| no_dex_pair | No active Uniswap V2 or V3 liquidity pair exists for GXAG | Means there is no public on-chain market. The token can only be traded through the project’s own app. That is a permissioned exchange, not a free market - and it removes price discovery from outside the team’s control. |
| suspicious_assembly | The bytecode contains assembly-level patterns our scoring engine treats as non-standard for ERC-20 | Not necessarily malicious, but unusual for a token that claims to be a simple wrapper around physical reserves. |
| mass_deployer | The deployer wallet has shipped multiple contracts (more than 5) | For a project that has only two public tokens (gold + silver), a deployer with many contracts on its history may indicate dev / test deployments or multiple parallel projects worth a closer look. |
| mass_funder | The wallet that funded the deployer has financed several other deployers in our graph database | This flag fires on cluster patterns. On its own it is a low-precision signal, but combined with the other flags above it adds to the centralization picture. |
Composite risk score: 70/100 in our scoring model. That is our calibrated threshold above which we classify a token as “Dangerous” rather than “Safe”. For comparison, a deterministic honeypot scores 100, while PAXG (Paxos Gold) scores in the low single digits because none of these flags fire on its contract.
The comparison that matters: PAXG and XAUT
Silver and gold backed tokens already exist on Ethereum and have for years. Their contracts are public, audited, and deliberately constrained:
- PAXG (Paxos Gold) -
0x45804880De22913dAFE09f4980848ECE6EcbAf78. Non-upgradeable. Mint controlled by Paxos’s regulated custodian role. Monthly attestation reports of the physical gold in custody. NYDFS-regulated. - XAUT (Tether Gold) -
0x68749665FF8D2d112Fa859AA293F07A622782F38. Non-upgradeable. Mint controlled by TG Commodities Limited. Quarterly reserve attestations published. - PMGT, AABBG, DGX - similar pattern. The trade-off between centralization (custodian risk) and on-chain immutability (no upgradeable logic) is the foundation of these tokens.
GXAG’s combination of upgradeable_proxy + hidden_owner + unrestricted_mint is the inverse of this pattern. The team retains the technical ability to mint tokens at will and change the contract logic at any time. Whether they will or will not do so is a question of trust, not of math.
What the Google searches reveal
Our GSC data shows users finding this contract via two query patterns:
- Raw address lookup:
"0xea4bc384184a5ccb02a079ea76931c57732c5de4"(and variants withgxag). These users have received the address from somewhere and are pasting it into Google to see what comes up. Position 7-8 on Google. They see our RektRadar analysis page, Etherscan, and not much else. - Site-restricted search:
site:gimbutiscoin.com "0xea4bc384184a5ccb02a079ea76931c57732c5de4"- explicitly looking for the address on the official site. The official site references the address inside its JavaScript bundle but does not list it on any indexed HTML page. So this search returns no Google snippet, even though the address really is there.
Both patterns are textbook due diligence. Both end with the user lacking the technical context to evaluate the flags above.
This article is here to bridge that gap.
What this is, and what this is not
This is not an accusation that Gimbutis Coin is a scam. The team has a real product (the apps work, the streams play, the support channels respond). They may have rational business reasons for the contract design choices (mobile-first UX, KYC-gated minting, dispute reversibility for regulated custody). Many fintech-adjacent projects make exactly these trade-offs.
What this is: a public on-chain audit of a token’s smart-contract structure. The flags are objective facts derived from bytecode and on-chain state. What you do with them depends on your risk tolerance and what guarantees you actually need from a “backed” token.
If you are about to send funds to acquire GXAG and you care that the token is backed 1:1 by physical silver that cannot be diluted by the issuer, you should be asking:
- Where is the proof-of-reserves attestation? Who audits the physical silver custody?
- Why is the contract upgradeable? Under what process can the implementation be changed?
- Who holds the owner / admin role? Is it a multisig? A regulated custodian?
- What restricts the
mint()function? Is there an on-chain cap tied to attested reserves?
The team has the URL, the apps, and the social channels to publish answers. The fact that the address is not surfaced on any indexed page of the official site, even though it lives inside the JavaScript bundle, is itself a useful piece of information.
How to check this yourself in 10 seconds
Drop either contract address on RektRadar and you will see the full flag list, the deployer cluster, and the on-chain state. No signup, no card:
If you have official documentation or audit reports that address the flags above, we are interested - reach out via the rektradar.io contact page and we will update the analysis to reflect any verifiable disclosures.
Methodology note
Analysis pulled from our PostgreSQL token_analysis table at 2026-05-22. The token was first analyzed on 2026-05-02 via our factory-watcher service. The risk score (70/100) is the aggregate of our scoring engine across the flags listed above, weighted by their historical correlation with confirmed scams in our 36 263-token reference set. The Google Search Console data covers 90 days ending 2026-05-22 and is filtered to the two RektRadar pages indexed for this contract. Full signal catalogue at rektradar.io/signals.