ARCHITECTURE
Four Engines.One Deterministic System.
OBEX separates the protocol into four consensus-critical engines. Each engine controls a different source of uncertainty. Together, they define how participation, blocks, transactions and rewards are handled.
OBEX
α-I
PROOF-OF-EFFORT
Participation
α-II
HEADER VALIDATION
Headers
α-III
CANONICAL ADMISSION
Admission
α-T
REWARD DISTRIBUTION
Tokenomics
CANONICAL STATE
01 · PARTICIPATION
Who Gets To Participate?
OBEX uses RAM-hard Proof-of-Effort combined with a Verifiable Random Function (VRF) to make participation expensive in physical resources rather than simply expensive in capital.
A participant generates a cryptographically verifiable proof of effort. The protocol uses that proof to establish eligibility without requiring every participant to hold a large financial stake.
LIVE STATE · PARTICIPATION
PROOF GENERATED 9f3a…c2e8
VRF VERIFIED
ELIGIBLE
In simple terms
Instead of:
“Own more tokens → gain more influence.”
OBEX uses:
“Perform verifiable work → become eligible to participate.”
The mechanism combines a large memory-bound computation with cryptographic randomness and Merkle proofs. The work is expensive to generate and inexpensive to verify.
Technical layer
- RFC 9381 ECVRF
- Ristretto255 / Ed25519
- BLAKE3
- RAM-hard memory construction
- Merkle authentication proofs
02 · HEADERS
Which Block Is Actually Valid?
Traditional blockchains can temporarily produce competing valid blocks. OBEX’s header engine establishes deterministic validation rules intended to prevent conflicting headers from becoming valid at the same height.
A header either satisfies the protocol’s equalities or it does not. There is no discretionary fork-selection process layered on top.
In simple terms
Instead of:
“Two blocks exist. The network eventually decides which one wins.”
OBEX is designed around:
“Only one block satisfies the rules.”
Technical layer
- Deterministic header validation
- Canonical state transitions
- Deterministic finality rules
- Fork rejection by construction
FORKLESS BY EQUALITIES
03 · ADMISSION
Who Gets To Go First?
Transaction ordering is one of the most valuable forms of discretion in blockchain infrastructure. If a participant can influence ordering, they may be able to extract value from the transactions around yours.
OBEX makes transaction admission canonical. Transactions are ordered according to protocol-defined rules rather than discretionary block-producer preference. This removes a major class of reordering-based MEV from the protocol design.
In simple terms
Instead of:
“The block producer decides what goes first.”
OBEX establishes:
“The protocol decides what goes first.”
Technical layer
- Canonical transaction ordering
- Transaction-ID based admission
- Deterministic execution sequence
MEV-LESS BY DESIGN
OBEX does not claim that every conceivable form of economic extraction disappears from every application. It targets the underlying source of one of the most important classes of MEV: discretionary transaction ordering.
04 · TOKENOMICS
Who Gets Rewarded?
The identity of the block proposer should not determine the economic outcome. OBEX uses proposer-agnostic reward rules designed to make rewards a function of protocol-defined participation rather than privileged position.
In simple terms
The system shouldn’t reward you simply because:
“You happened to be the person who proposed the block.”
OBEX establishes:
“Rewards follow the rules of the protocol.”
Technical layer
- Proposer-independent reward distribution
- Deterministic reward calculation
- Protocol-defined economic outcomes
THE RESULT
Same Inputs.
Same Rules.
Same Result.
Critical protocol behaviour should be reproducible. Given the same valid inputs, an independent implementation should be able to derive the same outcome. That principle extends across the system:
Participation
Who is eligible.
Headers
Which blocks are valid.
Admission
Which transactions execute first.
Tokenomics
How rewards are calculated.
Together they form the canonical OBEX state.
WHY IT MATTERS
Determinism Becomes More Valuable
When Money Is Involved.
For simple applications, unpredictable ordering or temporary forks may be an inconvenience. For financial infrastructure, they can become an economic problem.
Trading systems, tokenized assets, automated strategies and onchain markets need predictable execution. They need to know what executes, when it executes, and under which rules it executes.
OBEX is designed around that requirement. Not maximum theoretical throughput. Not endless protocol discretion.
Predictable execution. Verifiable rules. Deterministic outcomes.
TECHNICAL FOUNDATION
Specification First.
Implementation Second.
OBEX is built from a byte-precise protocol specification. Consensus-critical components are implemented in Rust with:
#![forbid(unsafe_code)]The implementation is designed around deterministic execution, golden test vectors and explicit protocol rules.
OBEX / PROTOCOL
SPEC v2
Every consensus-critical rule should be explicit, reproducible and independently verifiable.
WHAT OBEX IS NOT
No Black Box.
No Hidden Ordering Rules.
OBEX isn’t built around a collection of vague promises. The protocol defines its behaviour.
- Participation is defined.
- Header validity is defined.
- Transaction ordering is defined.
- Rewards are defined.
The system should not need a human explanation to determine what the protocol does.
The rules are the explanation.
THE MISSION
Make Onchain Finance More Deterministic.
Blockchains don’t have to eliminate every form of uncertainty. But where protocol behaviour can be made deterministic, it should be. OBEX is built around that belief.
- Participation should be verifiable.
- Block validity should be deterministic.
- Transaction ordering should be canonical.
- Rewards should follow rules, not privilege.
And when those principles are combined, financial applications can operate on infrastructure where the rules are known before the transaction arrives.
PROTOCOL STATUS
- NETWORK
- Robinhood Chain
- CHAIN ID
- 4663
- EXECUTION
- EVM
- FINALITY MODEL
- Deterministic OBEX protocol rules
- TRANSACTION ADMISSION
- Canonical
- PARTICIPATION
- RAM-hard Proof-of-Effort + VRF
- CRYPTOGRAPHY
- RFC 9381 ECVRF · Ed25519 · BLAKE3
- IMPLEMENTATION
- Rust · #![forbid(unsafe_code)]
- TOKEN
- $OBEX · Robinhood Chain
- STATUS
- Reference implementation live · mining window open