01
Users need the outcome they authorized
A wallet or app should be able to sign constraints and receive the state-machine outcome those constraints allow, not a hidden route, silent fallback, or degraded fill.
Fair DeFi protocol for wallets, apps, venues, and validators
Fair DeFi
with rules in the path.
Fair Outcomes gives wallets and apps a bounded Fair DeFi path: transactions are admitted and ordered by validator-client rules, then settled by on-chain intent, offer, account-closure, and report checks instead of hidden order or route control.
Native fair validator clientOn-chain Fair DeFiAccount-set closureBounded atomicity modes
Fair Domain
slot execution state
mode
proof-valid
8
invariants
4
markets
84
pages
Ingressreceipt quorumwitnessed
Ordercommit before reveallocked
Closureaccount setbounded
Settleintent + reportverified
Deterministic admission, reveal, account fencing, account closure, and settlement checks in one fair-domain path.
What this fixes
A fair trading primitive before the protocol detail.
Fair Outcomes is not a faster private relay or a promise to remove every trading advantage. It is a bounded Fair DeFi design where fair order and fair settlement are both checked by public protocol rules.
02
Apps need bounded atomic settlement
Swaps, liquidations, auctions, and downstream DeFi actions need declared account sets, compute bounds, CPI limits, and atomicity modes before fair ordering begins.
03
Validators need a fair lane worth running
The protocol design pays for admission, reveal, Fair Proof Bundle availability, replay, and proof-valid settlement instead of letting participants buy position inside the fair batch.
Problem
The technical problem starts in the transaction supply chain.
Modern transaction supply chains route sensitive DeFi flow through RPC peering, private relays, bundle systems, priority fees, aggregators, RFQ venues, and PropAMMs. Those systems improve landing and liquidity, but they also create hidden points where order, route, inclusion, quote quality, and settlement semantics can be exploited.
01
Ordering discretion
Validators and transaction supply-chain actors can monetize sequencing when profitable trades, oracle updates, liquidations, or swaps depend on relative position.
02
Private flow opacity
Private paths can improve landing reliability, but they also normalize privileged blockspace access and often give searchers stronger atomicity than ordinary users receive.
03
Settlement ambiguity
A user can approve one economic result and settle another when quotes, routes, solver choices, account sets, fees, rebates, or downstream calls are not binding on-chain.
Architecture
A full-stack fair execution path.
Fair Outcomes connects wallet intent, ingress evidence, validator ordering, runtime fences, on-chain settlement, account-set closure, Fair Proof Bundles, and economics into one auditable protocol.
1
Witnessed ingress
Gateways and witnesses issue signed receipts for transaction commitments, propagation policy, cutoff time, and fair-domain routing.
2
Fair validator client
A native pre-transaction envelope path admits, commits, orders, reveals, validates, fences, schedules, executes, and proves fair-domain batches.
3
On-chain Fair DeFi
Users sign intents, venues and solvers submit binding offers, and settlement programs verify candidate universes, fills, fees, rebates, refunds, and reports.
4
Bounded launch and economics
The MVP starts with native single-transaction settlement, explicit runtime bounds, quote bonds, fair-work rewards, and replay-verifiable launch gates.
Native validator client
Fairness is enforced in the execution path.
The fair envelope is a pre-transaction object. The validator commits admission before randomness, reveals payloads after order commitment, validates the inner transaction, fences protected accounts, schedules conflicting transactions by dependency graph, and requires settlement claims to fit declared bounds.
Commit-before-randomness
Prevents leader-controlled order grinding after admission.
Prevents leader-controlled order grinding after admission.
Dependency scheduling
Preserves committed order for all conflicting account sets.
Preserves committed order for all conflicting account sets.
Fair/normal fences
Block normal-lane insertion around protected fair batches.
Block normal-lane insertion around protected fair batches.
Account-set closure
Require selected offers and downstream calls to use declared accounts before fair ordering.
Require selected offers and downstream calls to use declared accounts before fair ordering.
Core flow
1Envelope admission
Validate receipt quorum, policy, fee ticket, expiry, nullifier, declared bounds, and forced-inclusion status.
Validate receipt quorum, policy, fee ticket, expiry, nullifier, declared bounds, and forced-inclusion status.
2Batch commitment
Publish admitted root, excluded root, reason codes, protected account set, and policy hash before order randomness.
Publish admitted root, excluded root, reason codes, protected account set, and policy hash before order randomness.
3Reveal, closure, and settlement
Threshold-decrypt after order commitment, then validate the inner Solana transaction, account-set closure, atomicity mode, and on-chain intent constraints.
Threshold-decrypt after order commitment, then validate the inner Solana transaction, account-set closure, atomicity mode, and on-chain intent constraints.
4Proof-valid replay
Replay rejects invalid fair-domain ordering, bypassed fences, unavailable Fair Proof Bundles, invalid reveals, or malformed execution reports.
Replay rejects invalid fair-domain ordering, bypassed fences, unavailable Fair Proof Bundles, invalid reveals, or malformed execution reports.
Formal guarantees
Designed for proof, replay, and audit.
The paper includes a formal specification and bounded model checking under ideal cryptographic assumptions, plus Fair DeFi safety invariants for deterministic settlement, account fences, quote integrity, Fair Proof Bundle availability, and atomic composability.
Conflicting order cannot invert
Earlier committed conflicting transactions must complete or fail before later conflicting transactions execute.
Normal-lane fences cannot be bypassed
Protected fair-domain accounts cannot be touched by ordinary traffic around a fair batch unless the domain's deterministic exception rules allow it.
Intent constraints cannot be bypassed
Min output, approved venues, expiry, fees, downstream programs, and fail-closed policy are enforced by the settlement program.
Winning offer selection is deterministic
Single-intent fills and batch clearing must select or reject offers by public rules, not by private arrival order or solver discretion.
Firm quote degradation cannot settle
A firm committed quote that falls below promised terms fails or produces attributable bond and refund consequences.
Atomic composability is all-or-nothing
The selected settlement mode defines whether the work settles in one transaction, a fair atomic sequence, or staged escrow with deterministic rollback paths.
Fair Proof Bundle non-availability has consequences
Proof roots are not enough; replay and certification depend on reconstructable Fair Proof Bundle data.
Off-chain discovery cannot alter settlement
Aggregators, makers, and solvers may propose candidates, but the chain verifies the selected result before it can settle as FairDeFiSettled.
Economics
Fairness must be the profitable strategy.
The market design replaces private-orderflow revenue with fair-work rewards. Validators earn for proof-valid slots, witnesses earn for receipts, committees earn for reveal work, venues price and bond quote risk, and solvers compete to improve user outcomes rather than extract from order or settlement control.
Admission market
Capacity allocation without paid intra-batch ranking.Fair-work market
Rewards for admission proofs, reveal, fences, schedules, Fair Proof Bundles, and replay-valid batches.Quote-risk market
Firm, reserved, conditional, indicative, and best-effort quote classes.Solver market
Public surplus sharing instead of private bundles around users.Whitepaper
Read the complete protocol specification.
The full paper covers protocol objects, validator-client architecture, replay validity, committee design, fair/normal account fencing, account-set closure, atomicity modes, Fair Proof Bundle finality, Fair DeFi settlement, economic equilibrium, launch gates, and the deployment plan.
84pages
38sections
3atomicity modes
Complete native validator-client protocol
Protocol objects, ingress, scheduling, account fences, and replay-valid batches.
Protocol objects, ingress, scheduling, account fences, and replay-valid batches.
Bounded on-chain Fair DeFi settlement
Intents, offers, candidate universes, account-set closure, reports, bonds, refunds, and settlement modes.
Intents, offers, candidate universes, account-set closure, reports, bonds, refunds, and settlement modes.
Economic equilibrium and market design
Incentives are separated across admission, proof work, quote risk, user refunds, and solver competition.
Incentives are separated across admission, proof work, quote risk, user refunds, and solver competition.
FAQ
Scope and claims.
Does Fair Outcomes eliminate all MEV?
No. It targets specific extractive mechanisms inside certified fair domains: content-based reordering, private fair-domain bundles, normal-lane bypass, unjustified exclusion, hidden route changes, quote degradation, and settlement outside user constraints. It does not eliminate public arbitrage, market making, inventory-risk compensation, or off-chain latency advantage.
What does 100% on-chain mean here?
It means the binding parts of a fair trade are verified by the state machine: user authorization, candidate universe, selected offer or clearing rule, settlement transfers, fees, rebates, refunds, bond consequences, execution report, and declared downstream DeFi composition. Off-chain systems can still discover prices and propose routes.
Does the protocol require a new validator client?
Yes. The complete design assumes a native validator-client implementation plus Fair DeFi programs for intents, offers, settlement, reports, bonds, account-set closure, and mode-specific replay checks.
Can users still choose normal execution?
Yes. Wallets can expose guaranteed, balanced, and fast execution modes. The important rule is that fallback from fair execution to normal or private routing must be explicit and signed, not silent.
What makes the economics stable?
Fair fees pay for admission capacity and proof work rather than rank. Validators are compensated for verifiable fair behavior, venues price and bond quote risk explicitly, users can receive deterministic refund paths, and solvers are redirected into public surplus creation.