Vorliq peer propagation lets nodes receive and, when explicitly enabled, broadcast signed user transactions and newly mined blocks. Receiving nodes validate payload shape, signatures, proof of work, block linkage, duplicates, and reserved-address rules before any local state changes.
A valid user transaction accepted into the pending pool can be relayed to eligible peers as a safe envelope. A receiving node verifies sender and receiver addresses, amount, timestamp, public key, signature, duplicate identity, and spendable confirmed balance before adding it to pending transactions.
A locally mined block can be relayed to eligible peers. A receiving node only applies the block when it is exactly the direct next block, its previous hash matches the local latest block, proof of work is valid, and the existing local blockchain validation path accepts it.
VORLIQ_PEER_BROADCAST_ENABLED=false is the safe default. Production nodes can receive and validate peer payloads without pushing outbound data until the operator chooses to enable broadcast.
VORLIQ_PEER_RECEIVE_ENABLED=true allows safe receive routes, but every payload is still treated as untrusted. Peer transactions cannot claim SYSTEM, VORLIQ_TREASURY, or LENDING_POOL as a public sender.
Validly shaped peer blocks that are not the direct next block are quarantined with reasons such as not_next_block, possible_gap, possible_fork, or ahead_candidate. They are not applied automatically, and a peer chain never replaces the local chain through propagation.
GET /api/peers/propagation/status
GET /api/peers/propagation/events?limit=25
GET /api/admin/peers/propagationThe event log stores safe metadata only: event ID, timestamp, direction, type, peer URL, status, reason, transaction ID, block index, block hash, and a short safe message. It does not store raw payloads, raw signatures, public keys, private keys, tokens, raw IPs, user agents, server paths, or environment values.
chain.json, pending.json, registry.json, or peer_events.json.