Метка: user safety

Prepared from community chat archives (Telegram/WhatsApp), screenshots, and a short video provided by participants. This report analyzes patterns of communication, token‑economic claims, market structure, and user outcomes. It is not legal advice. All individuals are treated with presumption of good intent; conclusions are framed as risk assessments grounded in evidence.

1) Executive Summary

Across months of posts and Zoom updates, participants were encouraged to believe in three routes to relief: (1) Akasha1111 (AK1111) and its supposed “Layer‑0” future; (2) a Dubai OTC option; and (3) a Funds Withdrawal process. In practice, the community experienced:

• Markets without depth (e.g., AK1111 shown with a spectacular Fully Diluted Valuation while real 24h volume hovered around ~$60k on a single DEX venue).

• Promised yields (supernodes, ultra‑supernodes, airdrops) that remained accounting entries rather than cash‑settled payouts.

• A serial cycle of announce → delay → re‑announce, including “24–48h” withdrawal timelines that did not clear for multiple users.

• Data collection contradictions: first, users told to provide wallet and personal data to leaders; later, leaders claimed no lists were necessary because “everything is in the back office” — yet they simultaneously promised to “email” users while acknowledging they did not have many users’ emails.

• Information control: critical voices labeled as FUD/negativity; people asking concrete questions threatened with bans or removed.

• Human harm: a charity donor (Mukisa Erik) documenting how the freeze affected children he supports in Uganda; others speaking about lost savings and mental stress.

Bottom line: The available evidence fits a pattern of non‑delivery wrapped in motivational messaging. Technically, the “Layer‑0” claim is unsupported by the required infrastructure; economically, the token’s observable liquidity is far too low to realize the paper valuations presented to users; operationally, refund/withdrawal processes lack verifiable audit trails. Until large‑scale user‑controlled, on‑chain settlements occur — and are independently auditable — the project should be treated as high risk.

2) What We Analyzed (Method)

1. Primary material: dozens of screenshots from Telegram/WhatsApp groups (HODL DAO Leadership; other subgroups), including pins and admin posts; a short Ugandan charity video.

2. Cross‑reading: recurring names, talking points, and dates were mapped into a timeline to see whether promised states (e.g., “90% conversions done,” “withdrawals within 24–48h,” “big news Wednesday”) were followed by verifiable outcomes for users.

3. Technical sanity checks: Basic tokenomics math, market‑microstructure logic, and infrastructure requirements for a real Layer‑0 network were applied to the claims.

4. Risk‑of‑harm lens: We considered how communication patterns shape user incentives — especially when money is frozen and emotions are high.

We deliberately avoid conclusions that require privileged data. Instead, we show what would have to exist for the claims to be true.

3) The Narrative the Community Was Sold

• “Layer‑0” Akasha1111 (AK1111). The token was repeatedly described as foundational infrastructure (not a meme coin), with talk of nodes and supernodes. In real Layer‑0 ecosystems (Polkadot/Cosmos/Avalanche), you can point to independent validators, relayers, cross‑chain messaging, SDKs, explorers, public binaries, and third‑party projects building atop the stack. None of this was presented here.

• “Supernodes / Ultra Supernodes.” Users were encouraged to “convert liquidity” into nodes and expect monthly airdrops (often framed as 2%×4). That is, paper yield accruing inside dashboards.

• “24–48h withdrawals.” The community was told that withdrawal requests (e.g., via “Akita”) were being processed within two days. Several users publicly showed that their requests remained pending beyond the promised window.

• “Data collection for refunds.” Leaders demanded wallet addresses and personal data via upline chains, yet later claimed lists were not needed — while also stating they didn’t have emails for many users.

• “Big news Wednesday / special Zooms.” Announcements of upcoming announcements became a pattern. A five‑minute Zoom with no substantive update was framed as progress; requests for a Dubai office address or direct meeting yielded no verifiable location.

This story arc is a textbook announce–delay loop. It keeps hope alive without creating the only state change that matters: user‑controlled, on‑chain settlement.

4) Market Reality vs. Presentation

4.1 The FDV Mirage

Several screenshots show AK1111 with > $100B fully diluted valuation (FDV) while the 24h volume is ~ $61,910, and the token appears only on one DEX. FDV is computed as price × max supply (here, 1B tokens). In thin markets, a small trade can mark the last price — causing FDV to balloon—while no one could actually sell at that valuation. Presenting FDV without context misleads non‑expert investors.

4.2 Liquidity Depth, Not Daily Volume

What matters for exits is depth and resilience — order‑book (or AMM) capacity to absorb sales without moving price. A single DEX pair with ~$60k/day turnover cannot support community‑wide redemptions. Even if genuine (and not wash/cycling), such volume means that a handful of moderate sellers would collapse price or sit in queue for weeks.

4.3 Bot‑like/Programmed Flow (How It Works)

On AMMs, a project wallet can trade with itself or a cluster to simulate activity. Telltales include: symmetric buy/sell bursts, quick reversion to a target price, and a counterparty concentration that does not match organic growth. Without independent LPs, this creates motion without demand. If real buyers existed at scale, listing on multiple reputable exchanges with market‑maker support would follow; we do not see evidence of this.

Conclusion: The market footprint is inconsistent with the grandiose valuation story and incapable of delivering the promised yields to ordinary users.

5) The “Layer‑0” Litmus Test

A network can call itself Layer‑0 if it connects Layer‑1 chains via shared security or messaging, with independent nodes, public repos, SDKs, and third‑party deployments.

What would we expect to see:

• Node binaries, testnets, peer lists, staking/validator docs;

• Message relayers and proofs visible on‑chain across at least two L1s;

• Tooling (CLI, SDK); explorers with public endpoints;

• External developers using the stack.

What the materials show: references to “nodes” only inside the project’s own dashboard — no public infra, no independent validators, no developer ecosystem. That points to a token with a dashboard, not an L0 network.

6) Supernodes, Airdrops, and Paper Gains

Participants were told that converting LP funds into (ultra) supernodes could produce monthly airdrops (e.g., 2% per drop × 4). Practical issues:

• Yield without exit = fiction. A 32% month on a dashboard is not income if it cannot be withdrawn to a user‑owned wallet and sold at a price close to the dashboard’s implicit valuation.

• Mismatched accounting. Screens show $0 rewards, missing LP entries, and statements that funds “exited to another wallet” with a TXID. If the destination wallet is not user‑controlled, this is custody leakage — the opposite of a payout.

• No reconciliation. A legitimate program would present: request ID → on‑chain TXID → user’s known wallet → spendable funds. That chain of proof is absent.

7) Conversions, Personal Data, and Contradictions

There is a persistent process confusion:

• Users are told to send wallet + personal information (name, address, etc.) through leaders to support.

• Subsequent posts claim “no lists needed; everything is in the back office”, while also promising email notifications even though “we don’t have user emails.”

• Some leaders insist only upline is allowed to communicate with support; others publicly deny responsibility when asked hard questions.

From a data‑protection standpoint, this is risky. Blockchain payouts do not require PII; they require correct wallet addresses. PII funnels, especially through private chats, increase exposure to phishing, doxxing, and impersonation, while adding no cryptographic assurance.

8) The 24–48h Withdrawal Loop

Multiple admin posts insist that queue backlogs are cleared and everything is “up to date.” In the same threads, named users (e.g., Arnold, Donna, others) report withdrawals placed weeks earlier still pending. This “announce–delay loop” is a classic pattern in distressed schemes: the promise horizon remains always two days away; dissent is reframed as negativity.

A project that truly fixes conversions would publish a public, immutable payout ledger: a Merkle root of all payout requests with per‑request proofs, plus on‑chain TXIDs to user wallets. Nothing like this has been shared.

9) Governance Through Positivity Pressure

The moderation approach equates hard questions with “lack of faith.” Members asking about real office addresses or accountability are dismissed or banned. Leaders advise “stay positive,” “trust the process,” “big news Wednesday.” This communication style reduces collective bargaining power and erases the audit trail inside chats (deleted messages, removed critics). It also leaves well‑meaning members isolated.

10) Human Cost and Secondary Scams

The Ugandan charity video shows a child in extreme need. Mukisa Erik explains that he intended to fund this work from expected HODL profits; the freeze has immediate real‑world consequences. Others describe five‑figure losses, family stress, and regret.

Crisis attracts secondary predators. At least one participant advertises a “new platform” to “recover funds.” Historically, recovery scams prey on victims twice. Any redirection to outside platforms should be treated with maximum suspicion.

11) Timeline Highlights (from the archives)

• FDV vs. Volume snapshot: AK1111 shown with ~$102B FDV; 24h volume ≈ $61,910; only venue mentioned: BaseSwap (DEX).

• “Layer‑0” claims challenged: community members asked for definitions; no infra details provided (no public nodes, no repos).

• Supernode pitch: example math of 32% monthly airdrops appears; later users report $0 rewards and missing LP.

• Withdrawal promises: recurring “24–48h” statements; users post that payouts remain pending from late August into September.

• Data‑collection confusion: leaders demanding lists; others saying lists are unnecessary; claim of future email notifications while lacking emails.

• Dubai office request: user asks for address to visit; no verified address provided.

• 5‑minute Zoom updates: minimal content; “big news soon”; critics labeled negative.

• Removals: outspoken members (e.g., Audrey) reportedly removed.

• Escalating frustration: posts like “my nodes not adjusted,” “no cent back from LP,” “over 100 days beyond 90‑day window.”

The consistency of these records across different people and days strengthens the credibility of the pattern.

12) Risk Assessment (Technical, Economic, Operational)

Technical risk: The Layer‑0 label is unsubstantiated. Without public infra, “nodes” are a UI concept, not a network.

Economic risk: A single DEX with ~$60k/day cannot clear community‑wide exits; paper yields cannot be realized. This creates a valuation / liquidity mismatch.

Operational risk: Conflicting instructions, missing audit trails, and positivity‑driven moderation are characteristic of non‑transparent control. The “funds exited to another wallet” messaging is especially alarming — it acknowledges custody movement without user control.

Regulatory risk (indicative): If yields were marketed as predictable and the token was positioned as an investment with managerial effort driving returns, some jurisdictions may treat this as a securities‑like offering; collection of PII without a lawful basis and controls raises data‑protection issues; if payouts rely on unlicensed intermediaries, AML exposure exists. (Local counsel should be consulted.)

13) What Evidence Would Change This Assessment

1. Scalable on‑chain settlements to user‑controlled wallets, not custodial addresses, with TXIDs published in a tamper‑evident ledger.

2. Public L0 infrastructure: code, nodes, independent validators, cross‑chain proofs, third‑party builders.

3. Reputable listings with organic multi‑venue volume and order‑book depth — not just ticker presence.

4. A third‑party audit/attestation reconciling dashboard balances and claimed airdrops with on‑chain events.

Absent these, caution is warranted.

14) Action Plan for Affected Participants

This section is pragmatic. Use it to protect yourself and coordinate with others, regardless of your view on intent.

1. Preserve evidence

   • Export chat histories (use Telegram Export), save screenshots, download Zoom clips.

   • Hash files (SHA‑256) to prove integrity; keep a simple chain‑of‑custody log.

2. Map your transactions

   • List every deposit TXID, wallet, and platform screen that references it.

   • If told that “funds exited” to another wallet, demand the exact TXID and the destination address; verify on a public explorer.

3. Prove control of your wallets

   • For addresses you claim as yours, make a dust spend (send a tiny amount) or sign a message to demonstrate ownership; store proofs.

4. Coordinate safely

   • Create a private victims’ group with vetted admins; beware of “recovery platform” pitches.

   • Appoint a documentation lead; maintain a shared evidence index.

5. Regulatory outreach (jurisdiction‑specific)

   • Prepare a concise package: timeline, amounts, screenshots, TXIDs, and a short cover letter explaining what you were told and by whom.

   • Consider local consumer‑protection, financial‑services regulators, and cybercrime units.

6. Data‑protection hygiene

   • Do not send additional PII; blockchain refunds do not require it. If requested, ask for the legal basis, controller identity, storage period, and deletion policy.

7. Mental and financial health

   • Talk to trusted friends or a counselor; avoid chasing losses or doubling down elsewhere. Scammers exploit urgency; slow down decisions.

15) Red Flags Checklist (Seen Here)

• Grandiose FDV with microscopic liquidity and single‑venue trading.

• Infrastructure claims (Layer‑0) without public nodes, repos, or third‑party usage.

• Yield dashboards without cash settlement.

• Announce–delay loops (e.g., 24–48h) while old requests remain pending.

• Custody drift: “funds exited to another wallet” not controlled by the user.

• Data‑collection contradictions and ad‑hoc PII funnels.

• Suppression of critique: deletions, bans, “stay positive” pressure.

• No physical accountability (no verifiable office address or responsible legal entity).

• Emergence of secondary recovery pitches in the same chats.

If a single project exhibits three or more of these simultaneously, risk of non‑delivery is high.

16) Ethical Note on Faith and Hope

Some posts invoke faith, positivity, or divine justice. Hope has value — but financial systems require verification. A just outcome is not created by optimism; it is created by auditable settlement. Empathy for well‑meaning leaders does not change the need for proof.

17) Conclusion

The collected artifacts depict a community kept in motion by promises, positivity, and perpetual next steps, while the few verifiable numbers (DEX volume, pending withdrawals, lack of public infra) point in the opposite direction. In this configuration, paper balances are claims, not assets. The deciding event — user‑controlled, on‑chain payouts at scale — has not been demonstrated.

Until that changes, treat all valuations and yields as non‑realizable, protect your data, and organize for accountability. The human stakes — from families to charity beneficiaries — demand nothing less.

Annex: How to Read Your Own Situation in 15 Minutes

1. Open the DEX pair and note: pool size, 24h real volume, price impact of a test trade. Ask: Could 100 average users exit without 20–40% slippage?

2. List your “dashboard balances,” then ask: Can I withdraw them to my wallet today? If yes, test with a small amount.

3. If told “soon”: ask for TXIDs of other users’ successful payouts in the last week (with their consent). Verify on‑chain.

4. Search public code, nodes, docs. If absent, it’s not Layer‑0.

5. Re‑read any admin post that frames your questions as “negativity.” Healthy systems welcome audits; unhealthy ones silence them.

End of English version.

18) Case Study — Vitaliy Dubinin’s Sept 12 Update & Thread (Why It Matters)

What was said (verbatim gist from the screenshots):

• Akasha nodes → first airdrop of Andy is happening very soon.

• Presale ended; official website, swap and coin launch soon; Andy website goes live at launch.

• New blockchain “Inception” has been in development; chain + explorer expected live by Sept 14; DEX app by Sept 24; CoinMarketCap application live by Oct 6.

• A new partnership can compensate LP balances and allow profits; details later.

• Team is working non‑stop; avoid negativity; I (Dubinin) don’t control deliverables; I’m just relaying info.

• In replies, criticism (“same stories”, “people invested real money and now you are promising airdrops”) is met with: “You are free to exit the group.”

• Despite the chat UI labeling Dubinin as “owner” of the group, he writes: “It’s not my project; I’m just keeping the group informed.”

18.1 Why this deserves separate scrutiny

This thread crystalizes the core dynamics of the project: date‑bound promises, shifting objects of hope, and a distancing of accountability by visible leaders.

18.2 Verifiable claims (convert to a checklist)

Create a shared, time‑stamped log and check each item publicly:

1. Inception chain + explorer live (Sept 14)

   • Must include: chain‑ID, RPC endpoints, explorer URL, block height progression, validator set, public repos.

   • If it appears only as a landing page with no moving chain, mark not delivered.

2. DEX application live (Sept 24)

   • Identify contracts (factory/router/pairs), addresses, verified source on explorer, TVL and unique LPs.

   • A “coming soon” front‑end without on‑chain contracts ≠ delivery.

3. CoinMarketCap “application live” (Oct 6)

   • “Application” is not a listing. Ask for the submission ticket ID, the exchange venues that will supply market data, and the circulating supply methodology.

   • If no exchange with organic volume exists, CMC listing is unlikely.

4. Andy airdrop “very soon”

   • Require: snapshot block height, Merkle root, claim contract address, vesting schedule, and proof the tokens are transferable to user‑controlled wallets.

   • Publish a public claims dashboard with per‑address proofs and TXIDs.

5. LP compensation via new partnership

   • Demand a written term sheet: who the counterparty is, legal entity names, source of funds, payment schedule, and escrow.

   • Any offer that requires new deposits, KYC by Telegram list, or off‑chain wallets should be treated as non‑credible.

18.3 Contradictions and governance signals

• Role vs. responsibility. The UI tag “owner” contrasts with “not my project.” If a person curates the information pipeline while moderating dissent (e.g., “You are free to exit the group”), they are functionally accountable for what that pipeline promotes.

• Airdrop substitution. Offering an Andy airdrop to holders of Akasha nodes substitutes delivery instead of honoring prior redemption pathways (LP refunds, pending withdrawals). This is a classic pledge‑for‑pledge swap that increases project complexity while postponing cash settlement.

18.4 How a genuine launch would look (what to request immediately)

• Public repos under an organization account; reproducible builds, binaries, and config.

• Independent validators and a transparent validator admission policy.

• Working explorer showing blocks, transactions, and validator signatures.

• Airdrop mechanics published with code (Merkle distributor) and immutable parameters.

• Exchange transparency: name the exchanges, pairs, market makers, and liquidity commitments pre‑launch.

18.5 Community playbook for this thread

• Pin a countdown for each date. When a date lapses, record Delivered / Partially / Not delivered, with screenshots.

• Standardize a Questions Pack to post after each claim:

  1. Where is the chain‑ID, RPC, explorer?

  2. Contract addresses (router/factory/token) and verified source?

  3. Airdrop: snapshot, Merkle root, claim contract, vesting?

  4. TXIDs of successful user payouts this week?

  5. Legal entity names and registered addresses behind any “partnership”?

• If answers are deleted or critics removed, append that to the evidence log (time, message link).

18.6 Risk assessment for the Dubinin update

• Delivery risk: High. Multiple promises with near‑term dates and no technical artifacts at announcement time.

• Accountability risk: High. The separation of “informing” from “owning” decisions, despite an owner/admin role, disperses responsibility.

• Investor‑protection risk: High. Airdrops and new chains are being used as narrative bridges while legacy obligations (LP refunds, pending withdrawals) remain unverified.

Takeaway: Treat these statements as testable hypotheses, not progress. Measure delivery on‑chain, not in chat.