VargaCoin. Technischer Überblick.
Wie das VGC-Netz heute funktioniert, welche Regeln bereits implementiert sind und welche Mainnet-Parameter vor dem finalen Consensus-Freeze noch gehärtet werden.
Dies ist technische Projektdokumentation für das VargaCoin-DEV-Netzwerk. Sie ist kein MiCA-Kryptowerte-Whitepaper, kein Angebot zum Erwerb von VGC, keine Aufforderung zum Kauf und kein Antrag auf Zulassung zum Handel.
Ein unabhängiges öffentliches Ledger für VGC.
VargaCoin ist eine eigenständige Proof-of-Work-Blockchain mit VGC als nativem Asset. VGC ist kein Token auf einer fremden Chain und besitzt keine feste Bindung an Bitcoin, Euro, Forint oder eine nationale Währung.
Das aktuelle öffentliche DEV-Netz dient dazu, Konsensverhalten, SHA-256D-ASIC-Mining, Wallets, Transaktionen, Explorer-Daten, Coinbase-Reife und den Netzbetrieb vor einem getrennten Mainnet-Start zu testen.
Full Nodes validieren eine gemeinsame VargaCoin-Chain.
VargaCoin Core basiert auf Bitcoin Core 31.1 und verwendet dessen UTXO-Transaktionsmodell, Script-Validierung, SegWit/Taproot-Ära-Primitiven und Peer-to-Peer-Node-Architektur mit VargaCoin-spezifischen Chainparametern und Branding.
Jeder Full Node validiert Blockheader, Proof of Work, Transaktionen und Konsensregeln selbstständig. Explorer- und Pooldaten sind Komfortansichten; maßgeblich ist die von validierenden Nodes akzeptierte Chain.
Offenes SHA-256D-Mining.
Kompatible SHA-256D-ASICs suchen Blockheader unterhalb des VargaCoin-Netzwerk-Targets. Der öffentliche Stratum-Dienst verteilt Jobs und Pool-Shares mit niedrigerer Share-Difficulty; nur Arbeit, die zusätzlich das Netzwerk-Target erfüllt, kann ein VargaCoin-Block werden.
Pool-Share-Difficulty und Netzwerk-Difficulty sind unterschiedliche Werte. Ein Share weist Arbeit gegenüber dem Pool nach; ein Block muss das aktuelle VargaCoin-Konsens-Target erfüllen.
Die öffentliche DEV-Chain verwendet derzeit 150 Sekunden Zielabstand, ein 24-Stunden-Retarget-Fenster (576 Blöcke) und DEV-Min-Difficulty-Verhalten. Das wird ausdrücklich nicht als finaler Mainnet-Konsens bezeichnet. Der Mainnet-Difficulty-Algorithmus wird vor dem Release Candidate ausgewählt, getestet und eingefroren.
Eigentum wird durch ausgebbare Outputs dargestellt.
VGC-Transaktionen geben bestehende UTXOs aus und erzeugen neue Outputs. Nodes prüfen Signaturen, Scripts, Beträge und anwendbare Konsensbedingungen, bevor Transaktionen und Blöcke akzeptiert werden.
Eine VGC-Empfangsadresse ist öffentliche Routing-Information und kein Private Key. Der Private Key bzw. WIF kontrolliert die Ausgabe und muss geheim bleiben.
Neu geminte Coinbase-Outputs benötigen derzeit 100 weitere Blöcke, bevor sie ausgabefähig werden. Wallet und Explorer unterscheiden unreife Mining-Rewards vom verfügbaren Guthaben.
Vorhersehbare Ausgabe, vorbehaltlich des finalen Mainnet-Freeze.
Der geplante Mainnet-Emissionsplan startet mit 12,5 VGC pro Block und halbiert sich alle 840.000 Blöcke. Bei 150 Sekunden Ziel-Blockzeit entspricht das ungefähr vier Jahren pro Halving und ergibt eine beabsichtigte maximale Ausgabe von rund 21 Millionen VGC; Implementierung und Rundung werden vor dem Code-Freeze nochmals verifiziert.
VGC besitzt keinen garantierten Marktpreis. Falls VGC später gehandelt wird, entsteht der Marktwert durch unabhängige Käufer und Verkäufer und kann bis auf null fallen.
Mainnet startet mit neuem Genesis. Die DEV-Historie wird nicht zerstört.
Die aktuelle DEV-Chain und das zukünftige Mainnet sind getrennte Ledger. DEV-Blöcke, DEV-Guthaben und geminte DEV-VGC werden nicht kopiert, getauscht oder automatisch dem Mainnet gutgeschrieben.
Beim Mainnet-Start beginnen Mainnet-Guthaben mit dem neuen finalen Genesis und den öffentlich angekündigten Mining-Regeln. Technisch könnte dasselbe Schlüsselmaterial weiterverwendet werden, falls die Formate kompatibel bleiben; das Mainnet-Guthaben ist trotzdem null. Zur klaren Netztrennung wird eine neue Mainnet-Wallet empfohlen.
Geplant ist, die DEV-Chain nach dem Mainnet als schreibgeschütztes historisches Testarchiv zu erhalten. Frühe ASIC-Blöcke, Transaktionen und Testergebnisse bleiben damit überprüfbar, obwohl DEV-VGC kein Mainnet-Guthaben besitzt.
Self-Custody bedeutet: Der Schlüssel kontrolliert die Coins.
VargaCoin unterstützt native Bech32-Adressen mit vgc1-Präfix. Die VargaCoin WebWallet erzeugt oder importiert Schlüssel lokal, verschlüsselt im Browser gehaltenes Private-Key-Material und signiert Transaktionen clientseitig vor dem Broadcast.
Ein WIF ist eine Exportdarstellung eines privaten Schlüssels. Wer einen gültigen Private Key besitzt, kann die von ihm kontrollierten Outputs ausgeben. Nutzer sollten sichere Backups führen und WIF/Private-Key-Daten niemals veröffentlichen.
Pool-Abrechnung und On-Chain-Nachweis sind unterschiedliche Ebenen.
Der öffentliche Pool nimmt Stratum-Shares kompatibler SHA-256D-Miner an. Share-Daten messen beigetragene Arbeit; ein Blockreward existiert erst, wenn ein Kandidatenblock vom VargaCoin-Netz akzeptiert wurde.
Blockhashes, Höhen, Transaktionen und Reward-Outputs sollten im Explorer oder direkt über einen validierenden VargaCoin-Node geprüft werden. Ein Pool-Dashboard allein ist kein Konsensnachweis.
Proof of Work ist nur so stark wie die Arbeit, die die Chain absichert.
Ein junges SHA-256D-Netz kann plötzlichen Hashrate-Schwankungen, gemieteter Hashrate, tiefen Reorgs sowie Timestamp-/Retarget-Randfällen ausgesetzt sein. Genau deshalb läuft das aktuelle Netz ausdrücklich als öffentliche DEV-Phase.
Vor dem Mainnet soll ein adaptives Difficulty-Design eingefroren und getestet, Reorg-Verhalten geprüft, mehrere unabhängige Full Nodes betrieben, reproduzierbare Releases veröffentlicht und die Mainnet-Go/No-Go-Checkliste abgeschlossen werden.
Kein technisches Dokument und kein Softwaredesign kann zukünftigen Marktwert, unterbrechungsfreien Betrieb oder vollständige Freiheit von Software- und Netzwerkfehlern garantieren.
Implementierung und Launchplan überprüfen.
Öffentliche technische Spezifikation · Technical Paper v0.2 · September 2026