GrossusBlockchain — Official Record Hub

Neutral public record for the Geton / Grossus Blockchain era.

This page provides a concise, verifiable overview of how the GROSH voucher mechanism worked, how peer-to-peer deposits and withdrawals were processed, what created liquidity risk, and where transactions can be independently verified. This is not marketing and not an investment offer.

Evidence-first Neutral No promises / no ROI Consistent with court submissions
Verify transactions in Explorer Read the 3-level explanation

Core truth: deposits and withdrawals were processed through peer-to-peer voucher trading. If no one was buying vouchers, no one could sell them. Liquidity depended on market demand — not on any guaranteed redemption.

Historical continuity note: Digital assets created during the Geton / Grossus Blockchain era continue to exist across independent wallets and public blockchains. Their ongoing presence reflects historical issuance and peer-to-peer custody — not active operation, obligation, or continuation of the former platform.

LEVEL 1 For general public

What happened, in plain language

  • GROSH voucher was a legal and operational mechanism used because Geton was not a bank and could not move EUR balances internally between users.
  • Deposits: users who deposited (bank or Coinbase conversion to EUR) were buying GROSH vouchers from users who were selling them.
  • Withdrawals: users requesting withdrawal were selling their GROSH vouchers to users who wanted to buy vouchers.
  • All matching was peer-to-peer. The company was a platform provider and transaction processor, not a counterparty providing liquidity.
  • What went wrong: as demand slowed, voucher buying stopped → trading stopped → liquidity disappeared. This created frustration and misinformation.
  • MLM promoters (sometimes) amplified wrong expectations (ROI / guaranteed payout). Those claims were outside platform design and outside founder control.
  • Verifiable fact: users who did not sell their vouchers still have them; balances and full transaction history remain checkable via Explorer or login-based interfaces.
P2P No guaranteed liquidity Verifiable (Explorer) Neutral technical record
LAUNCH DISCIPLINE Reborn-safe posture

Recycling is a technical option — not compensation

Token recycling provides a voluntary mechanism to permanently burn legacy tokens and create a new on-chain participation reference within a transparent protocol. It does not guarantee profit, recovery, or value. Participation is optional and at the user’s own risk.

What recycling is?
  • Voluntary, user-initiated technical action.
  • Legacy tokens are permanently and irreversibly burned.
  • A new on-chain participation reference is created under a separate protocol.
  • Rules, caps, and mechanics are explicitly defined and enforced by code.
  • No linkage to prior balances, expectations, or claimed losses.
What recycling is not?
  • Not compensation, refund, settlement, or legal remedy.
  • Not an investment, yield product, or promise of return.
  • Not a recovery mechanism or acknowledgment of obligation.
  • Not a guarantee of liquidity, valuation, or future outcome.
Reconsideration & consequences
Some users may choose to interact with a separate technical recycling interface. This interface exists solely to execute irreversible token burn and to record a new on-chain participation reference under a different protocol.

Access is optional, final, and not related to any compensation, recovery, or entitlement. No recommendation is made and no outcome is implied.

External technical interface: https://geton.global
Open Explorer Fact Sheet Documents
LEVEL 2 For prosecutors / journalists

Primary references

Archived user interface documentation (2020–2021)

During active operation, the Geton platform included interface-level explanations and walkthroughs for all primary user actions.

These materials are preserved here as historical reference only, illustrating how users interacted with the system at the time. They are not promotional and are not part of any current offering.

These interface explanations correspond directly to transactions visible in the public Grossus Blockchain Explorer and are provided solely to assist factual review of system behavior.

On-chain asset references (Ethereum — archival)

While Grossus Blockchain was used as an inter-platform transaction layer, core assets of the Geton ecosystem were deployed as ERC-20 tokens on the Ethereum blockchain and stored in system-controlled cold wallets.

The following addresses are provided solely as verifiable references for supply structure and emission logic at the time of operation.

  • Business Development Supply (BDS)
    ERC-20 address: 0xbddedc1b0b98663ce03727f0699a5556536f897b
    Purpose: controlled release of tokens to support platform activities (user actions, rewards, DPMC emission logic).
  • Ecosystem Supply
    ERC-20 address: 0xF2C23Ac37959B0fb161AC8e7d0b49b7F326851C2
    Purpose: aggregate of tokens released into circulation and mirrored in Grossus Blockchain balances.
  • Liquidity Pool
    ERC-20 address: 0x84c744f9b8f07e288fc3f151c716c6ff6bc1ff5c
    Purpose: assets acquired through GROSH mining stake mechanics to support internal exchange activity.

Token movements between Ethereum and Grossus Blockchain were executed via controlled bridging processes and are publicly traceable on-chain.

Multichain supply audit & bridge references (public)

In addition to the Grossus Blockchain transaction layer, core Geton ecosystem assets were deployed as ERC-20 tokens on public blockchains.

To provide an objective and independently verifiable overview of historical and current token supplies across chains, a dedicated audit reference interface is maintained.

This audit view documents how token supply was distributed across: Ethereum (original issuance), BNB Smart Chain, Polygon, Arbitrum, and other supported networks — including bridge-locked balances and circulating supply.

Public audit reference:
https://audit.grossusblockchain.com/
Live multichain supply tables with contract-level data and bridge state.
  • Total
    Total issued supply on a given blockchain (original deployment or mirrored issuance).
  • Liquidity Pool
    Assets allocated for internal exchange activity and GROSH mining stake mechanics.
  • Ecosystem
    Tokens released into user circulation and reflected in Grossus Blockchain balances.
  • Bridge Locked
    Tokens locked on one chain to represent assets bridged and circulating on another chain.
  • Circulating
    Tokens actively available to users on the given blockchain at that time.

These figures are derived directly from on-chain contract states and are provided for transparency, historical accuracy, and independent verification. They do not imply liquidity guarantees, valuation, or compensation.

Technical clarification for tax authorities (neutral)

The following materials provide a factual and technical explanation of how GROSH vouchers, peer-to-peer matching, and fiat transaction flows operated within the Geton ecosystem.

These documents are published solely to assist accurate technical classification in administrative and expert review contexts. They do not constitute legal advice, tax advice, or guidance regarding individual procedural rights or deadlines.

Important: Procedural rights, deadlines, and remedies depend on the circumstances of each individual case and applicable law. Users and third parties should consult independent legal counsel before taking any legal or tax-related action.

These materials may also be referenced in individual administrative or advisory contexts, where appropriate.

LEVEL 3 For developers / geeks

Network architecture summary

Grossus Blockchain was a purpose-built transaction network operated as a one-node (single validator) ledger, with a SQL-backed data layer and an explorer providing public access to transaction history. The goal was auditability and usability, not speculative mining.

  • One-node ledger (single validator / controlled environment)
  • SQL-backed state (operationally deterministic storage)
  • Public Explorer (transaction-level visibility)
  • Wallet mapping (email-linked user access for simplicity)
  • Bridging (migration paths to public chains over time)
explorer auditability migration traceability
FACT SHEET short, strong, verifiable

Key facts

Peer-to-peer mechanics

Voucher buying and selling occurred between users. Deposits matched to sellers; withdrawals matched to buyers. The platform provided the interface and processing, not guaranteed liquidity.

Liquidity reality

If no users were buying vouchers, sellers could not sell. Liquidity was a market condition, not a platform promise.

Independent verification

Transactions are publicly accessible via Explorer. Users who did not sell vouchers still have them and can verify history.

DOCUMENTS stable reference set

Download references

These documents are published as a stable public reference set. Filenames are kept stable for citation consistency.

Disclaimer: This material is provided solely for factual and technical clarification of historical system mechanics and does not constitute legal advice, financial advice, or a representation regarding individual rights, remedies, or statutory deadlines.
Press One-Pager (PDF) GROSH Voucher — Whitepaper (PDF) GROSH — Mechanics (PDF)

Tip: host all PDFs on the same domain and keep stable URLs. If updates are required, use versioning only where legally necessary.

VERIFICATION verify, don’t debate

Independent sources

Use these sources to verify transaction history and supply structure. This hub is an index — the explorer and audit tables are the canonical views.

Open Explorer Open Supply Audit
What to cite in disputes
Cite the Explorer for transaction timestamps and flows. Cite the Supply Audit for contract-level supply, bridge-locked balances, and circulating supply. Use PDFs only as structured explanations and indexes of the above sources.