CIVICNET v3.0.7
HYBRID VALUE LAYER (HVL) IS NOW LIVE ON MAINNET
A Native, Protocol-Level Token Issuance System for CivicNet
No Smart Contracts • No Bridges • No External Execution Layer
MAINNET ACTIVATION: 2026-09-01 08:00 UTC
CivicNet Core v3.0.7
INTRODUCING THE HYBRID VALUE LAYERThe
Hybrid Value Layer (HVL) is now active on the CivicNet mainnet.
HVL is a native token-issuance system implemented directly inside the CivicNet protocol and consensus rules.
Unlike ERC-20, SPL, or other smart-contract token systems, HVL tokens are
not programs running inside a virtual machine.
They are native blockchain objects validated directly by CivicNet nodes.
There is no smart-contract execution layer to deploy, audit, upgrade, or trust.This means token issuers cannot introduce arbitrary contract logic, hidden proxy upgrades, reentrancy vulnerabilities, or custom execution behavior.
HVL intentionally trades unlimited programmability for a smaller and more predictable attack surface.
DESIGN PHILOSOPHY
HVL was designed around three permanent principles:
1. NO ON-CHAIN GOVERNANCE OR TOKEN VOTINGHVL does not introduce token-holder voting, DAO-style parameter control, or protocol governance.
Consensus parameters remain part of CivicNet's protocol and node configuration model.
The goal is to avoid governance capture, low-turnout manipulation, plutocracy, and voting-based attacks.
2. NO PROTOCOL-LEVEL PRICE SETTINGCivicNet HVL does
not contain:
- Automated Market Makers
- Liquidity pools
- Bonding curves
- Protocol swap pricing
- Token price voting
The blockchain does not attempt to determine what a token should be worth.
Price discovery remains external to the protocol.
3. MINIMIZE TRUST AND ATTACK SURFACESeveral more powerful mechanisms were deliberately rejected during development when they introduced unnecessary third-party trust or new manipulation vectors.
HVL focuses on a fixed collection of native operations whose behavior is known and consensus enforced.
COLORED UTXO ARCHITECTURE
HVL extends CivicNet's existing UTXO transaction model instead of creating a separate account-based token database.
Every CivicNet transaction output can optionally carry:
tokenID = 256-bit token identifier
nTokenAmount = 64-bit token amount
An output carrying a token ID becomes a
"colored UTXO".
Because HVL uses CivicNet's existing UTXO architecture, basic token transfers inherit the same:
- UTXO ownership model
- Digital signature verification
- Double-spend protection
- Transaction confirmation model
- Blockchain reorganization behavior
TOKEN IDENTITYEvery HVL token receives a deterministic 256-bit Token ID derived from the first input outpoint of its issuance transaction.
tokenID = SerializeHash(tx.vin[0].prevout)
Because an outpoint can only be spent once, every Token ID is globally unique without requiring:
- A central registry
- A naming authority
- Token symbol reservation
- Governance approval
Token symbols themselves are intentionally
not globally unique.
Wallets and explorers therefore display information such as the full Token ID and issuer together with the token symbol.
NATIVE HVL TRANSACTION TYPES
TOKEN_TX_ISSUE — CREATE A TOKENToken creation happens through a native CivicNet transaction.
An issuer can define:
- Symbol — up to 12 characters
- Name — up to 32 characters
- Decimals — 0 to 8
- Initial supply
- CIVIC reserve amount
- Standard or vesting token type
- Fixed or mintable supply configuration
- Optional supply cap
- Optional mint expiry height
- Transfer-fee configuration
- Metadata information
There is no mandatory commit/reveal process.
A token can be created using a normal signed CivicNet transaction, subject to the protocol's anti-spam issuance fee.
TOKEN TRANSFERHVL token transfers use ordinary colored UTXOs.
Consensus verifies token value conservation:
Token Inputs = Token Outputs + Applicable Token Fee
Authorization is simply ownership of the UTXOs being spent, protected by CivicNet's normal signature rules.
TOKEN_TX_MINT — NATIVE SUPPLY EXPANSIONTokens configured with mint authority may issue additional supply.
Mint operations are authorized using the token's registered issuer identity.
Issuers can optionally define:
- A permanent maximum supply cap
- A mint-authority expiry block height
Once the expiry height is reached, additional minting becomes permanently unavailable.
Tokens issued without mint authority have fixed supply that cannot later be increased through HVL consensus rules.
TOKEN_TX_BURN — DESTROY TOKENSAny holder can voluntarily burn tokens they own.
Burned tokens are permanently removed from current token supply.
No issuer permission is required because the holder is destroying their own token UTXOs.
CIVIC RESERVE & CONVERT_OUT
One of HVL's core mechanisms is its native CIVIC reserve system.
At token issuance, CIVIC can be committed to a consensus-controlled reserve output using:
OP_TOKEN_RESERVE
The reserve is not controlled by an ordinary private key.
The protocol recognizes a dedicated operation:
TOKEN_TX_CONVERT_OUTA holder can destroy the required token amount and release CIVIC from the associated reserve according to the conversion relationship established at token issuance.
The original rate is derived from:
Reserve CIVIC / Initial Token Supply
The conversion rate is
not modified by voting, governance, market price feeds, or an automated market maker.
HVL therefore treats the reserve mechanism as redemption infrastructure rather than a protocol-controlled token market.
NATIVE VESTING
HVL supports tokens with protocol-enforced vesting schedules.
A vesting token may define:
- Start block height
- Cliff duration
- Total vesting duration
- Beneficiary
Vesting parameters become immutable after issuance.
Before the cliff is reached, vested tokens cannot be released.
After the cliff, the protocol calculates the amount that has become available according to the vesting schedule.
Release happens through:
TOKEN_TX_VESTING_RELEASE
and requires authorization from the designated beneficiary.
This can be used for:
- Team allocations
- Developer allocations
- Advisor allocations
- Investor distributions
- Long-term ecosystem allocations
IMMUTABLE TRANSFER-FEE OPTIONS
HVL provides two optional protocol-native fee models.
They are configured during issuance and
cannot be changed afterward.
RECIPIENT_CURVEA percentage of transfers may be directed to a predefined recipient.
The fee can decay from a starting rate toward an ending rate over a defined number of blocks.
BURN_FLATA fixed percentage of each transfer is permanently burned.
This reduces the token's current supply over time.
These parameters are immutable specifically so token creators cannot silently alter transfer economics after holders have acquired the asset.
ANTI-SPAM TOKEN ISSUANCE FEE
Token creation is intentionally simple, but completely free token issuance could allow uncontrolled blockchain spam.
HVL therefore implements a consensus-enforced adaptive issuance fee.
The base fee is derived from:
min(
Current Block Subsidy × FEE_BURN_MULTIPLIER,
MAX_ISSUANCE_FEE
)
The maximum issuance fee is:
50 CIVIC
HVL also monitors token issuance volume across the previous:
1,440 BLOCKS ≈ 24 HOURS
The fee tier changes according to network issuance activity:
| Issuances / 1,440 blocks | Base Fee Applied |
| Below 50 | 100% |
| 50 - 200 | 50% |
| Above 200 | 20% |
The resulting issuance fee is divided:
20% BURNED
80% AVAILABLE AS NORMAL MINER TRANSACTION FEE
The burn requirement is enforced by consensus validation.
A transaction attempting to bypass the required burn is rejected with:
bad-token-issue-insufficient-burn-fee
The issuance-volume tracker is also designed to restore its previous state during blockchain reorganizations.
METADATA WITH ON-CHAIN INTEGRITY VERIFICATION
HVL supports external metadata for:
- Token logo
- Description
- Website
- Social links
- Other token information
Instead of storing large media files directly on-chain, HVL stores:
metadataUri
metadataHash
The URI may point to IPFS or another external content system.
The associated SHA-256 hash is stored on-chain so wallets and explorers can verify that the retrieved metadata matches the content committed by the issuer.
This allows external metadata hosting without requiring users to blindly trust the metadata host.
IMMUTABLE METADATA OPTIONMetadata is updateable by the issuer unless the issuer permanently enables:
fMetadataImmutable
Once metadata is made immutable, future metadata modifications are rejected at consensus level.
CIVICNET SEAL — FUTURE PROOF-OF-EXISTENCE INTEGRATION
HVL already reserves:
poeAnchorHash
for future integration with the planned
CivicNet Seal Proof-of-Existence timestamping system.
The planned PoE integration is intended to function as a wallet/explorer trust signal rather than a new consensus requirement.
OFFICIAL HVL DESKTOP WALLET
A new CivicNet desktop wallet has been developed specifically for HVL.
The wallet runs a CivicNet node internally so normal users do not need to manually install and configure a separate node.
Features include:
- Native CivicNet mainnet synchronization
- Send / Receive CIVIC
- Native staking support
- Staking-only wallet unlock
- Wallet encryption
- Key import / export
- HVL asset browser
- Native token creation interface
- Logo upload
- Metadata / IPFS support
- Token transaction history
HVL BLOCK EXPLORER SUPPORT
The CivicNet explorer has also been extended for HVL.
Explorer infrastructure can track:
- Issued tokens
- Token IDs
- Issuer identity
- Total/current supply
- Decimals
- Mint authority/status
- Token holders
- Token transaction history
- Decoded HVL transaction operations
Token indexing is performed incrementally as blocks are processed rather than requiring a complete blockchain rescan for every query.
SECURITY MODEL
NO SMART-CONTRACT EXPLOIT SURFACEHVL exposes only protocol-defined operations rather than arbitrary smart-contract execution.
UTXO DOUBLE-SPEND PROTECTIONToken ownership inherits CivicNet's UTXO transaction model.
CONSENSUS-ENFORCED RESERVE CUSTODYReserve outputs cannot be spent using an ordinary private key.
SUPPLY RULES ARE PUBLICFixed and mintable supply characteristics are visible to wallets, explorers, nodes, and holders.
CONSENSUS-ENFORCED ANTI-SPAM FEESIssuance fee rules are validated by CivicNet nodes rather than enforced only by wallet RPC interfaces.
REORG-SAFE TOKEN STATEToken state and issuance-volume tracking are designed to restore correctly during blockchain reorganizations.
METADATA INTEGRITY CHECKINGSHA-256 metadata commitments allow wallets and explorers to detect altered external metadata.
NO HVL GOVERNANCE CAPTUREHVL does not contain token-holder governance or protocol voting.
NO PROTOCOL AMMCivicNet does not determine token market prices.
IMPORTANT — NODE & POOL OPERATORS
HVL is a
CONSENSUS RULE CHANGE.
Mainnet activation:
2026-09-01 08:00:00 UTC
HVL ships with:
CIVICNET CORE v3.0.7
Nodes running versions prior to v3.0.7 do not understand HVL transaction types.
Independent node operators, miners operating their own full nodes, and mining pool operators should upgrade to v3.0.7.Users mining through a pool via Stratum do not need to upgrade their own mining software solely because of HVL. The pool operator's CivicNet node must be current.
Production infrastructure and both CivicNet DNS seed nodes were upgraded before activation.
UBUNTU 22.04+ NOTEThe current v3.0.7 binary requires:
libdb_cxx-5.3.so
This library may not be installed by default on Ubuntu 22.04+.
If CivicNet Core does not start after upgrading, check the v3.0.7 GitHub release notes for the required Berkeley DB compatibility package/instructions.
WHAT COMES NEXT?
HVL development is divided conceptually into multiple stages.
PHASE 1 — CONSENSUSNative token transaction types and consensus validation.
PHASE 2 — ECOSYSTEM TOOLINGExplorer integration and official HVL desktop wallet.
PHASE 3 — DEVELOPER ECOSYSTEMDocumentation, SDKs and integration examples for developers building services and applications on HVL.
POTENTIAL PHASE 4 — NOT COMMITTEDAn application-layer order book or trustless peer-to-peer atomic exchange mechanism has been discussed.
If developed, it would remain outside HVL's protocol-level price-setting model.
CivicNet itself will not introduce an AMM or protocol-controlled token market.
