Verge Core XVG Node and Wallet Architecture

What Verge Core Implements for XVG Operators

Verge Core addresses the code needed to participate directly in the Verge network rather than interacting with XVG only through a hosted wallet or web service. The repository contains the full-node implementation, the `verged` daemon, the `verge-qt` wallet interface, RPC support, mining code, and network-facing peer-to-peer functionality. Its intended audience includes developers compiling the protocol, infrastructure operators running public services, and technically capable wallet users who need control over their software.

The network uses proof of work and a stated block time of 30 seconds. The README documents scrypt, x17, Lyra2rev2, myr-groestl, and blake2s as algorithms. Verge also documents separate mainnet and testnet ports, which makes testnet isolation a repository-level feature rather than something inferred from its name. Its supply schedule reaches 16,521,951,238 XVG, and the block reward table records no reward after block 7,200,001. Those are protocol and configuration facts, not evidence that the software is suitable for every deployment.

The repository also includes `verge-qt`, which is the graphical wallet, and `verged`, which is the infrastructure-oriented daemon. That separation matters. Operators running pools, exchanges, explorers, or public RPC nodes do not automatically receive SMSG indexing and relaying behavior. Security-conscious node configuration is therefore part of the product's design rather than an unrelated deployment preference.

How verged and verge-qt Divide Network Responsibilities

The clearest architectural distinction in the README is the default SMSG posture of the two binaries. `verge-qt` starts with SMSG enabled because it is normally used as a wallet. `verged` starts with it disabled because the daemon is commonly placed in pools, exchanges, explorers, and public RPC infrastructure. This prevents a public service from relaying, storing, and indexing secure-message data unless the operator deliberately enables it.

An operator can opt a daemon into SMSG with the `smsg=1` configuration key or command-line argument. Additional controls determine whether the daemon scans the chain and incoming blocks for chatkey funding or public-key data, and how many validated relay peers it tries to maintain. These settings expose SMSG as a configurable subsystem with startup scanning, incoming block processing, persistence, peer validation, inbox access, and outbound message handling rather than as a simple chat interface.

RPC is the main documented control surface. The README points to `RPC.md` for wallet, network, raw transaction, mining, and secure-messaging commands. This indicates that much of the daemon can be administered without operating the graphical wallet. However, the README does not document authentication policy details, TLS configuration, resource limits, database requirements, backup procedures, or production hardening steps. Those omissions matter when considering a public RPC node, especially one given access to a funded wallet.

SMSG Uses Wallet Addresses, Chatkeys, Relays, and Paid Retention

Verge Secure Messaging is described as paid, encrypted wallet-to-wallet messaging. A user starts with an ordinary wallet address and publishes a local chatkey for it. The shareable chatkey combines the Verge address and public key in the form `vergeaddress-publickey`. Another party can register that identity for sending, while each daemon maintains relationships with validated SMSG relay peers.

The workflow separates address creation, local chatkey publication, public-key retrieval, peer registration, sending, and mailbox reading. A newly created address does not itself prove that SMSG setup is complete. The process requires `smsgaddlocaladdress` and `smsggetpubkey`, followed by registration of the recipient's dashed chatkey through `smsgaddaddress`. Only then does `smsgsend` have the identifiers needed to address an encrypted message.

Retention is another protocol-specific constraint. Paid SMSG messages default to 31 days, and the sender may select a shorter period from 1 to 31 days. The README does not describe recipient controls over deletion, archival retrieval, fee accounting details, or recovery after an incorrect retention choice. The repository clearly defines an operational workflow, but users should not treat the README as a complete retention-policy explanation.

Building Verge Core from Source on Supported Platforms

The README documents build prerequisites but does not provide a complete build command. It points readers to `INSTALL.md` in the repository for installation guidance. Because the contents of that file are not included in the README, inventing `cmake`, `autogen.sh`, or Make invocations would risk producing an unreliable tutorial.

The stated compiler floor is GCC 9.0+, Clang 10.0+, or MSVC 2019+, with C++17 required and C++20 as the target. CMake 3.16 or newer is the recommended build system, and selective Boost components require Boost 1.70 or newer. The project supports Ubuntu 22.04 and 24.04, Debian 11 or newer, CentOS/RHEL 8 or newer, macOS 13 and 14, and Windows 10 and 11. Listed architectures include x64, ARM64, Apple Silicon, and x86 where applicable.

A first practical source-build step should therefore be to follow `INSTALL.md` for the selected operating system and verify that its compiler, CMake, and Boost setup matches the README matrix. The repository includes `configure.ac`, `autogen.sh`, `Makefile.am`, `depends/`, and `build-aux/`, so it is not obvious from the README whether a given platform should use the recommended CMake route, the Autotools files, or the bundled `depends/` workflow. That choice must be resolved from `INSTALL.md`, not guessed.

A First Daemon Run through the SMSG RPC Workflow

Once `verged` and `verge-cli` have been built and available on the system, the README provides a concrete first use through SMSG. The following command starts the daemon with SMSG enabled for that run. Infrastructure operators should explicitly review whether persistent SMSG storage and relay traffic are acceptable on the target host.

verged -smsg=1

The next commands create or select a wallet address, publish its local chatkey, and display the resulting public key. These operations act on the wallet associated with the running daemon, so wallet initialization and synchronization must already be configured according to `RPC.md`.

verge-cli getnewaddress "chat"
verge-cli smsgaddlocaladdress <youraddress>
verge-cli smsggetpubkey <youraddress>

After the recipient supplies a dashed chatkey, it can be registered and used as the destination of a paid message. The final argument in the documented example is the 31-day retention period.

verge-cli smsgaddaddress <theiraddress> <theirpublickey>
verge-cli smsgsend <youraddress> "<theiraddress>-<theirpublickey>" "hello" true 31

An encrypted wallet must be unlocked before chatkey or sending operations. The documented command passes `300` as the passphrase timeout. That command signature should be checked against `RPC.md` before relying on it in a longer operational sequence.

verge-cli walletpassphrase "your passphrase" 300

The inbox and outbox commands complete the local read path:

verge-cli smsginbox all
verge-cli smsgoutbox all

The README does not establish what these mailbox entries look like, so the expected result should be taken from `RPC.md`. A listed outgoing message would not, by itself, prove that the remote party has read it.

Verge Core Build Constraints and Operational Boundaries

The C++ migration is relevant when judging maintenance work. The README says the project has moved toward fewer external dependencies, smart pointers, RAII, standard-library threading, and C++17 with a C++20 target. It presents these as improvements to compilation, memory handling, and deployment. These are project claims rather than independently confirmed measurements, and the README supplies no binary-size, memory, or performance results.

The toolchain requirement itself is a real adoption constraint. A supported platform must have a sufficiently new compiler, CMake 3.16 or newer for the recommended route, and the required Boost components. Selective dependencies can lower the general dependency count while still requiring operators to install and match Boost correctly. Source builders also need to account for supported OS versions and architectures rather than assuming every POSIX environment is equivalent.

Verge Core is the wrong choice when the requirement is a managed XVG custody service, an official hosted wallet, or a zero-build node deployment. It is also a poor fit for operators who need documented production RPC security controls but cannot find sufficient guidance in the README. Public infrastructure has a particularly important SMSG boundary: SMSG is disabled by default in `verged`, which reduces unnecessary message handling, but enabling it introduces chain scanning, relay peer management, storage, and wallet operations that must be accounted for separately.

MIT Licensing and Verge Core Release Work

The repository identifies the Verge Core source under the MIT license. For adopters, this is relevant because it provides a permissive license basis for studying and modifying the source and distributing copies under the license's stated terms. This paragraph does not substitute for legal review of the full `LICENSE` file or any dependencies used by a particular build.

The repository is not archived, and the last push was on 2026-10-14. Releases listed around that push include `v27-beta4` on 2026-10-14, `v26.8` on 2026-08-28, and `v26.7` on 2026-07-02. That release history indicates ongoing work at the repository level, but it does not answer operational questions such as how migrations are tested, whether a node upgrade can be rolled back, or what compatibility changes occur between major versions.

For an infrastructure operator, upgrade cost depends on facts the README does not supply. It does not document the wallet database migration path, chain-state requirements, configuration deprecations, peer compatibility, or whether downgrading is supported. The source also presents modern compiler and platform floors, so an upgrade can affect the build environment as well as the binaries. Those details should be checked in `INSTALL.md`, `RPC.md`, and the release-specific notes before replacing a working deployment.

Editorial conclusion

Developers who need to build the XVG protocol stack or operate a node with RPC access may find Verge Core relevant, while users seeking a documented one-command deployment or managed wallet should look elsewhere. Adoption decisions should first verify the build instructions in INSTALL.md, platform-specific packaging, wallet backup procedures, and the exact RPC and SMSG exposure required by the intended deployment.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vergecurrency/verge on GitHub