Frozen configuration
Each epoch's voter registry, its keys, weights and total, is fixed under a config_id that every vote names. A vote counts only with the registry's weight.
SHA-256d / PROOF OF WORK / PoWit
Real work.Proofs thatendure.
The next chapter of GnB. SHA-256d mining for Bitcoin ASICs, finality earned by share work and checkpoints anchored in Bloch, both ways. A new chain with a clean genesis, built on an open code base.
Work in consensus. Cryptography in signatures.
WORK → FINALITY → ANCHORINGLAUNCH STATUS
PROOF OF WORKSHA-256d.
Bitcoin's 80-byte header, for ASICs
TARGET INTERVAL30 seconds
GhostDAG · ASERT difficulty
SUPPLY CAP12.5 million OBB
Four allocations, set in the genesis
FINALITYPoWit.
Weight earned through share work
01 / THE PROTOCOL
Every layer.
A reason to exist.
Produce blocks, finalize history and record checkpoints: three connected functions of ObenBlock.
01 / BLOCK PRODUCTIONSHA-256d
One hash. Two passes.
Bitcoin's header layout, byte for byte, with a commitment to the parent list in place of the previous block hash: the 32-bit nonce, version rolling (BIP 320) and a rollable time. The block id is the proof-of-work hash. The node serves pools through getblocktemplate and submitblock.
NO MERGED MINING · ASERT, 2 H HALF-LIFE · STALL RELIEF
02 / WORK-EARNED FINALITYPoWit + KES
Work has a memory too.
Witness weight is share work recorded in finalized history, with no stake, over a 28-day window. Each new share job needs fresh chunks of the attested block, so whoever runs the job server must hold the block. The specified growth cap bounds how fast the weight can change: renewals first, then at most 1/64 of the total per epoch. Capturing two thirds then takes at least about 18 days of visible growth, whatever the hashrate rented.
WEIGHT FROM WORK, NO STAKE · STICKY FINALITY
03 / MUTUAL ANCHORINGOBB ↔ BLOCH
Two networks. Connected histories.
Bloch's finalized checkpoints are recorded in ObenBlock transactions, and the first finalized checkpoint of each ObenBlock epoch, one every six hours, is recorded in Bloch. A record carries no proof that the witness set finalized it, so the specification makes every anchor advisory: a contradiction raises an alert and the operator decides.
ADVISORY · NOT A CONSENSUS RULE ON EITHER CHAIN
Architecture as described in the specification of 18 October 2026.Read the protocol design ↗
02 / FINALITY
Final means
strictly final.
Mainnet launches with PoCI, ObenBlock's strict finality profile, in force from the genesis. The first 4 epochs and one more of burial are proof of work only; strict finality starts at height 3,600.
| Votes | Casper FFG links signed with KES keysA link justifies its target with strictly more than two thirds of the configuration in force; a justified direct child finalizes its source |
|---|---|
| Weight | Share work, no stakeFrom finalized history, over a 28-day window of 112 epochs |
| Sticky finality | No reorg below a finalized checkpointA conflicting finalization raises an alert and waits for the operator |
| Stalls | No leak for finalityAbsence never changes the weight of a decision: without a quorum, blocks keep coming and finality waits. A KES-signed exit leaves at the next handoff |
| Growth cap on W | Renewal first, then at most W / 64 per epoch In the nodeTwo thirds of W takes at least 71 epochs, about 18 days, whatever the rented hashrate; work not admitted is dropped, not banked |
| Payments | Credit at finalityWallets and exchanges credit a payment once getfinalityinfo reports it finalized, not after N blocks |
PoCI · PROOF OF CORRUPTION OR INTEGRITY
From the genesisEvery finality decision ends in one of two verifiable objects: a finality certificate, or evidence that a key signed two votes the rules forbid. Nothing else changes the weight of a decision: no absence, timeout, partition or local clock.
Strictly more than 2/3
3 × voted > 2 × total. Two quorums of one configuration overlap in more than a third, so with under a third Byzantine weight they share an honest key.
Handoff
The next configuration enters into force only when the checkpoint that opens its epoch is finalized under the current one. Exits, bans and expiring weight wait for that handoff.
Absence pruning by the old committee
A key with no included votes in the 4 epochs (24 h) before a handoff is left out of the next configuration, but only when keys holding more than two thirds of the current one were present: a stall is not absence. It returns with a KES-signed rejoin message, under the growth cap.
Proof of Corruption
A double or surround vote by one key under one configuration is evidence. The key is excluded for 100 epochs, about 25 days. Absence, slowness or a vote for a losing branch are never punished.
Finality certificate
The proof of integrity: configuration, link and signatures worth more than two thirds of it, checked against the registry. Nodes keep one for every finalized checkpoint.
Without a quorum, blocks keep coming and finality halts until more than two thirds of the configuration vote again; recovery is a coordinated, explicit act, never automatic. Without stake, exclusion and the lost share rewards are the whole penalty: PoCI makes corruption detectable and attributable. PoCI is in force from height 3,600, after a launch buried under one epoch of proof of work. Read the PoCI design.
03 / ANCHORING
Two chains.
Anchored both ways.
Each chain records the other's finalized checkpoints. Neither direction is a consensus rule, and no anchor overrides a node's own finality.
BLOCH → OBENBLOCKBLA1 ANCHORS
Bloch checkpoints in ObenBlock
An anchoring wallet records Bloch's finalized checkpoint (epoch, root, height) in an ordinary ObenBlock transaction, with two unspendable marker outputs. Buried under SHA-256d work, it turns a rewrite of Bloch history behind it into a contradiction of a public, timestamped record.
- Format
- Version 1: a 33-byte root marker and a 20-byte
BLA1epoch and height marker, 546 base units each - Verification
- Anyone, with read-only Bloch RPC calls; verifiers choose whose anchors count
- Status
- In the code base
OBENBLOCK → BLOCHADVISORY
ObenBlock checkpoints in Bloch
One 84-byte record per epoch, every six hours: chain id, slot, block id, finalization time and a digest of the witness set that finalized it. A node started with --bloch-rpc reads the records its own Bloch node has finalized. By the specification, a contradicting anchor raises the finality alert and the operator decides; an agreeing one is reported as corroboration.
- Record
chain_id ‖ slot ‖ block_id ‖ finalized_at ‖ W-digest- Status
- Record format, node side and reference daemon in the code base; the Bloch registry needs the Bloch code base and is not built yet
- Next
- Certified anchors (OBIP-3) and a Bloch light client in the node (OBIP-4)
Both directions are documented in the repository.Read the anchor formats ↗
UNDER STUDY / BLOCH SIDECHAIN
A sidechain of Bloch.
Being studied.
ObenBlock is being studied as a sidechain of Bloch: a DEX, a bridge, the Bloch L2 and new features built across the two chains. Under study Nothing below is in the ObenBlock code base, and it is not decided whether any of it will launch.
DEXUNDER STUDY
Trading OBB on Bloch
A market for OBB on Bloch's L2, with caps fixed in code and settlement gated on finality, following the model being developed for GnB-SMH on Bloch.
BRIDGEUNDER STUDY
OBB between the two chains
A vault on ObenBlock and a wrapped token on Bloch, released only against finalized checkpoints. Which signers or proofs would secure it is part of the study.
L2UNDER STUDY
Bloch's L2 as the execution layer
Applications for OBB holders on Bloch's L2, with ObenBlock as the proof-of-work settlement and anchoring chain beside it.
NEW FEATURESUNDER STUDY
Built across both chains
Features that use both chains' finality, such as the mutual anchoring already in the code base, extended to applications.
What this means. A direction under study, not a roadmap commitment. Any part that moves forward would first be written as an ObenBlock Improvement Proposal, with its security model stated, before any code or launch.
04 / THE TECHNICAL FOUNDATION
Open on the outside.
Rigorous on the inside.
The GnB code base brings a BlockDAG, adaptive difficulty and hybrid post-quantum signatures. ObenBlock carries this architecture over to SHA-256d work, with every hardening rule in force from the genesis block.
DEFAULTML-DSA-65+FALCON-1024
OPTIONALSLH-DSA-128s+FALCON-1024
Post-quantum protection belongs to the signature layer: both halves of every signature must verify. Mining uses SHA-256d. Full cryptographic specification.
| Consensus structure | GhostDAGBlockDAG · k = 10 |
|---|---|
| Proof of work | SHA-256d80-byte header · Bitcoin's chain work · pow limit 0x1d00ffff · no merged mining |
| Difficulty | ASERT · 2 h half-life30 s target; after 3 minutes without a block the target doubles every 30 minutes |
| Finality | PoWit + KES keysShare-work weight, no stake, sticky finality; PoCI strict finality from the genesis |
| Work window | 28 days · 112 epochsEpochs of 720 blocks, 6-hour target |
| Identity | OBB · obb1… addressesgnb1… and bloch1… addresses are read as the same script |
| Networks | Mainnet + regtestNo public testnet |
| Anchoring | ObenBlock ↔ BlochFinalized checkpoints recorded in both directions, advisory |
Packages O2 to O9 of the relaunch plan are implemented in the code base. The growth cap (O10) has a reference model and vectors; PoCI (O11) is a design.
05 / CRYPTOGRAPHY
Two signatures.
Both must verify.
Every key pairs two post-quantum schemes, and a forgery has to break both. Below are the two signature suites and every hash, key and channel that protects a coin.
SUITE 0x0001DEFAULT
ML-DSA-65 + Falcon-1024
Two lattice schemes of different constructions: ML-DSA (NIST FIPS 204, Module-LWE) and Falcon (NTRU lattices). Wallets use it by default.
- NIST security level
- 3 (ML-DSA-65) and 5 (Falcon-1024)
- Public key
- 3,745 bytes
- Signature
- Up to 4,775 bytes
- Used for
- Transactions and spend policies, PoWit witness keys, node identity and signed messages
SUITE 0x0003OPTIONAL · CONSERVATIVE
SLH-DSA-128s + Falcon-1024
A hash-based scheme, SLH-DSA-SHAKE-128s (NIST FIPS 205, secure as long as SHAKE256 is), paired with Falcon. A forgery needs a break of a hash function and of a lattice problem.
- NIST security level
- 1 (SLH-DSA-128s) and 5 (Falcon-1024)
- Public key
- 1,829 bytes
- Signature
- Up to 9,322 bytes, about 7× slower to verify
- Used for
- Transaction signatures only: key addresses and spend-policy keys, valid from the genesis block
How the halves are bound. Each half signs its own message, which names the suite and the half and carries the transaction's signature hash. A key of one suite never verifies a signature of another, and a signature with one half removed never verifies. Wallet support. The command-line wallet creates keys of either suite; the browser wallet, PQ-PSBT and descriptors use the default suite for now. Legacy. ML-DSA-65 alone (suite 0x0002) stays valid only so that outputs locked to such keys remain spendable. It is non-standard, and wallets never sign with it.
| Proof of work | SHA-256d80-byte header; the block id is the proof-of-work hash |
|---|---|
| Transaction id | SHA-256dOver the canonical wire encoding |
| Merkle roots | Tagged SHA-256BIP 340-style tags for leaves and nodes; the witness root is committed in the coinbase |
| Signature hash | SHA3-256Commits to the chain id and to every spent amount and script, like Bitcoin's BIP 341 |
| Addresses | SHA3-256 of the public key, 20 bytesobb1q… for a key, obb1m… for a spend policy; gnb1… and bloch1… are read as the same address |
| Witness keys (KES) | 4,096 hybrid keys under one SHA3 Merkle rootOne key per 6-hour epoch, about 2.8 years; each earlier secret is erased |
| Wallet files | Argon2id + AES-256-GCMGnB and Bloch wallet files open unchanged |
| Peer connections | ML-KEM-768 + X25519Hybrid key exchange, HKDF-SHA256, ChaCha20-Poly1305 |
| Node identity | Ed25519 + ML-DSA-65 ‖ Falcon-1024A peer's post-quantum key is pinned on first contact |
| Chain separation | Chain id 0x4F420001In every signature hash and PoWit message: no signature is valid on both GnB and ObenBlock |
Signature rules as specified in the consensus document; the suites are implemented and tested in the GnB code base.Read the signature rules ↗
06 / THE ECONOMICS
A clear cap.
From the very first block.
ObenBlock keeps the four allocations of the GnB tokenomics. Capped emission, halvings and vesting rules written in code.
12,500,000 OBB
MAXIMUM CAP · ACTUAL EMISSION MAY BE LOWER
MINING
72%9,000,000 OBBHalving every 4,204,800 blocks (about 4 years). No perpetual tail emission.
BLOCH CARRY-OVER
8%1,000,000 OBBSame Bloch Genesis-3 snapshot and same conversion as the GnB genesis.
TEAM
10%1,250,000 OBBLocked by consensus: a one-year cliff, then 36 monthly tranches.
FOUNDER
10%1,250,000 OBBThe same cliff and vesting rules as the team allocation.
A clean genesis. The same carry-over keys.
The genesis pays the carry-over exactly as GnB's genesis does: the same snapshot, the same fixed conversion, to the same 20-byte key hashes. Nothing mined or moved on the GnB chain is carried. The block subsidy ramps up linearly over the first 5,760 blocks (about two days); the subsidy withheld, about 3,080 OBB, is never issued.
07 / MAINNET LAUNCH
One mainnet.
Launch status.
The facts marked At launch are published when mainnet starts and are not known yet. Until they appear here and in the repository's release notes, there is no ObenBlock network to join. Compare them across more than one source before you rely on them.
| Status | Not launched |
|---|---|
| Launch time (UTC) | At launch |
| Genesis block hash | At launch |
| Seed nodes | At launchhost:18110 entries for --connect / --addnode |
| DNS seed | seed.obenblock.xyz At launch |
| Stratum endpoint | At launchFor SHA-256d ASICs; the address and the share difficulty are published with it |
| Explorer | obenblock.xyz/explorerShows mainnet data once the network runs |
| Web wallet | obenblock.xyz/walletKeys are decrypted and used only in the browser tab |
| Release binaries | obenblock.xyz/downloads At launchFiles and SHA-256 checksums |
| Networks | Mainnet and regtestNo public testnet |
|---|---|
| Chain id | 0x4F420001 mainnet · 0x4F420002 regtestGnB keeps its own chain ids: no transaction, attestation or share is valid on both chains |
| Addresses | obb1q… key · obb1m… policyRegtest: obb1t…, obb1n…. gnb1q…, gnb1m… and bloch1q… are accepted as the same script and shown as obb1… |
| Peer protocol | /obenblock/pq/1.0.0 |
| Default ports | 18110 P2P · 18210 RPCApart from GnB's, so one host can run both chains |
| Launch difficulty | Set by the genesis target At launchStall relief lowers a target set too high within hours, and the slow start makes early blocks pay almost nothing if it is set too low |
| Minimum chain work | 0 at launchNo release finality checkpoint or assumed-valid block at launch; later releases set them from independent nodes |
08 / ROADMAP
What comes next.
Proposed in the open.
Future changes are written as ObenBlock Improvement Proposals, adapted from Bitcoin's BIP process. Every one below is a Draft.
| OBIP | Title | Layer |
|---|---|---|
| 2 | Compact post-quantum finality certificates | Peer services |
| 3 | Certified Bloch anchors | Consensus, hard fork |
| 4 | Bloch light client in the node | Applications |
| 5 | Out-of-body PoCI vote aggregation | Consensus, hard fork |
| 6 | Commit-reveal votes in the vote window | Consensus, hard fork |
| 7 | Bloch-authorized finality recovery | Consensus, hard fork |
| 8 | Configuration floor and fast re-entry | Consensus, hard fork |
| 9 | Data availability sampling | Consensus, soft fork |
| 10 | Validity proofs of block execution | Consensus, soft fork |
| 11 | Operator-diversity metrics | API / RPC |
| 12 | Committee-based fast finality | Consensus, hard fork · informational |
| 13 | Settlement layer with forced exits | Consensus, hard fork · informational |
What they are. Proposals, not commitments: none has a reference implementation or test vectors yet, and parameters marked OPEN are undecided. OBIP-1 defines the process. What ObenBlock is today, PoCI included, is the base specification and not an OBIP. Post-quantum status. Pairing-based SNARKs, KZG and BLS aggregation are not post-quantum; they appear in the OBIPs only as laboratory baselines or rejected options.
Index, dependencies and suggested order of work in the OBIP README.Read the OBIPs ↗
09 / FOR BUILDERS
The code is open.
So is the next step.
Explore the repository, follow the relaunch packages and examine the rules. GnB's development history continues in the ObenBlock repository.
OBENBLOCK / SOURCE↗
# Start with the code.
$git clonehttps://github.com/gnb-smh/ObenBlock.git
$cd ObenBlock
git clone https://github.com/gnb-smh/ObenBlock.git cd ObenBlock
10 / THE NEW CHAPTER
The evolution,
made clear.
What changes with ObenBlock, and what carries over from GnB.
Is ObenBlock live yet?
Not yet. The mainnet launch is being prepared. The launch time, the genesis block hash, the seed nodes, the stratum endpoint and the release binaries are published at launch, in the launch status above and in the repository. Until then there is no ObenBlock network to connect to.
Is ObenBlock GnB's new name?
The GnB repository was renamed ObenBlock and keeps its history. ObenBlock itself is a new chain: a clean genesis, the OBB ticker and SHA-256d mining. The relaunch does not change the GnB chain.
What is PoCI, and when does it start?
PoCI (Proof of Corruption or Integrity) is a strict finality profile for ObenBlock: a frozen configuration per epoch, a quorum of strictly more than two thirds, a handoff between configurations, absence pruning authorized by the old committee, a 100-epoch exclusion on proven equivocation and a finality certificate. It is in the node from the genesis. The first 3,600 blocks (4 epochs plus one epoch of burial) are proof of work only; strict finality starts there.
Can rented hashrate take over finality?
Weight comes from share work in finalized history over a 28-day window, so a burst of hashrate does not buy instant weight, and checkpoints already final stay final. The growth cap in the node goes further: whatever the rented hashrate, reaching two thirds of the weight takes at least 71 epochs, about 18 days, visible the whole time.
Are my GnB and Bloch keys still valid?
Yes. A GnB keystore (v2 or v3) or the Bloch keystore you use today opens unchanged, and gnb1… and bloch1… addresses are read as the same script and shown as obb1…. The same key controls its coins on both chains; the chain id keeps the signatures apart. The carry-over is paid to the same key hashes as in GnB's genesis; balances from GnB's later history are not carried.
Can I mine ObenBlock with a Bitcoin ASIC?
The block header is Bitcoin's 80-byte layout, so SHA-256d ASICs do the work, with the 32-bit nonce, version rolling and a rollable time. The node serves pools through getblocktemplate and submitblock; the stratum endpoint for ASICs is published at launch. There is no merged mining.
Do Bloch anchors decide which chain is final?
No. An anchor is evidence, not a vote: a record carries no proof that the witness set finalized it, and anyone with a Bloch account can publish one. By the specification, a node that sees an anchor contradict its own finality raises an alert and the operator decides. Anchors that carry a verified finality certificate are a proposal (OBIP-3).
Do SHA-256d and PoWit do the same thing?
They serve different functions. SHA-256d is the proof of work used to mine blocks. PoWit is the finality layer: witnesses vote with weight earned from work shares, using keys that evolve each epoch. Wallets and exchanges credit a payment once it is finalized, not after a fixed number of blocks.
Which post-quantum signatures does ObenBlock use?
By default, ML-DSA-65 + Falcon-1024: every signature carries both, and both must verify. For transaction signatures, a holder can choose the conservative suite instead, SLH-DSA-128s + Falcon-1024, which adds a hash-based guarantee at about twice the signature size. Witness keys, node identities and signed messages always use the default suite. SHA-256d is the mining hash, not a signature.
Is there a testnet?
No public testnet. ObenBlock has one mainnet and a regtest network for local development and tests.
OBENBLOCK / OPEN BY DESIGN
docs/DESIGN-obenblock.md
docs/DESIGN-obenblock-poci.md
docs/obip/README.md