The Thesis
The value of any asset is its probability-weighted discounted future cash flow. Equity claims residual earnings, while a bond claims principal and coupons at known times. A derivative is a claim constructed from claims. A sukuk claims Sharia-permissible asset usage, and a tokenized real-world asset claims an off-chain cash flow.
Parametric insurance is a claim contingent on adverse outcomes. A sports prediction is a claim contingent on an event outcome. An intellectual-property royalty claims usage cash. To first order, every tradeable instrument reduces to such a cash flow. The claim is therefore the universal primitive of finance.
Existing infrastructure clears each claim family on a separate substrate. Equities clear at central securities depositories, derivatives at central counterparties, and prediction events at sequenced general-purpose chains. Sukuk clear at institutional channels with no retail pathway and no sub-day settlement. Tokenized real-world assets clear at a handful of permissioned platforms with single-jurisdiction wrappers. Brand and intellectual-property licensing barely clears at all.
Each system has its own compliance regime, settlement assets, margin pools, and reliance framework, with no formal interaction between them. Capital that could net across claim families sits idle in separate pools.
Moxie is a clearing and settlement layer for claims. Every claim family compiles into one clearing grammar, with a TemplatePack registry supplying the rules that distinguish each class. Each family uses the same chain. Pricing combines the claim’s intrinsic discounted cash flow, compliance requirements across 23 regulatory domains, and an adversarial counterparty model. The clearing program runs inside consensus, where it performs the calculation during execution.
Sports and other event-contingent markets are one product family within the protocol’s broader taxonomy. Moxie was first built for this family, under the hardest correlation, latency, and oracle conditions a clearing layer faces.
Three Layers
The architecture separates the claim, the admissible obligation transition, and the TemplatePack. Most systems combine them, which forces a new chain for every product.
The conceptual primitive is the claim: a future cash flow with a probability distribution over its timing and amount. It includes the payoff terms, the issuing or amending authority, the evidence that resolves its state, and the rulebook governing eligible holders. Regulators, trustees, and counterparties reason about the claim in these terms.
The protocol primitive is the admissible obligation transition: a state change in a claim’s lifecycle that moves economic authority. Transitions include issuance, attestation, transfer, margin update, netting, settlement, amendment, dispute, recovery, release, and revocation. Admission requires joint validation of authority, evidence, compliance attestation, reserved risk, execution certificate, settlement instruction, receipt, and reliance rulebook. Consensus commits the validated transition, so an invalid state cannot enter the record as a tradeable claim.
The product primitive is the TemplatePack: a claim family’s rulebook and machine-readable parameters. It specifies authority, evidence, eligible holders, settlement asset, risk model, dispute path, recovery path, reporting, and reliance. A new product family adds a TemplatePack and a lowering into admissible transitions. It uses the existing root transaction types, settlement grammar, and compliance model.
The Protocol
Moxie is a sovereign Layer 1 whose consensus, execution, and clearing form a single system.
The block executor runs three deterministic phases in fixed order. Phase 1 resolves attested outcomes and settles the claims that depend on them. Phase 2 clears all trading against the freshly resolved state: order books, automated market makers, convex batch auctions, and margin enforcement. Phase 3 processes everything else: transfers, staking, governance, and EVM calls. The protocol enforces this order and prevents reordering.
Every validator checks conservation of value after every block. The sum of account balances, clearinghouse deposits, market-maker reserves, and reserve-fund positions must equal total supply. A block that fails this check is invalid.
MoxieBFT Consensus
MoxieBFT extends HotStuff by prepending an event-collect phase to its standard pipeline. The pipeline runs through idle, proposing, event-collecting, voting, and committing. Event collection gathers oracle attestations before block finalization, so resolution evidence arrives before any trade executes against it. Message complexity stays linear in the size of the validator set.
An encrypted mempool removes front-running and sandwich attacks. Transactions use the validator set’s threshold public key for encryption. The validators decrypt them collectively only at execution time, so the proposer never sees plaintext before commitment.
Pricing
Moxie prices a claim using its cash flows, eligible holders, and counterparties. The first input is intrinsic value: the claim’s probability-weighted discounted cash-flow surface. The second is the admissible holder set. Compliance, jurisdiction, custody, tax, Sharia, securities, and insurance constraints determine who may hold or transfer the claim. This changes liquidity and therefore price, so compliance affects pricing as well as permission to trade.
The third input is counterparty state: inventory, beliefs, incentives, and hidden short-volatility exposure. These can move executable prices even when the cash-flow model is unchanged. Moxie models their effect explicitly. A market is a strategic system in which every inefficiency is some counterparty’s error.
The pricing layer selects a matching mechanism for each claim family. Bilateral institutional claims use request-for-quote, while liquid standardized claims use order books. Yes/no event claims use a market-scoring rule, pooled contingent claims use a batch auction, and streamed inventory uses a continuous market maker. All share the same claim grammar.
The event-contingent family couples belief and price directly. When a prediction market revises an outcome’s probability, a bounded multiplier reprices the corresponding spot claim inside the same block. The clearinghouse atomically recomputes margin against the new price. This mechanism is specific to the event-contingent family.
Clearing
One clearinghouse nets every position a holder carries across claim families. It computes portfolio margin over the whole book at once, so correlated positions offset. The collateral a holder must post therefore falls below the sum of isolated margins.
The clearinghouse runs inside consensus. Mark-to-market happens at the phase boundary of every block. Liquidation cascades are deterministic and execute in the same block as the price movement that triggers them. There is no settlement delay, and no counterparty risk is carried past the block boundary.
Collateral is also scheduled in time. A contingent event resolves in hours, but isolated systems lock capital around it for weeks. Moxie tracks which capital backs each obligation and when. It frees that capital as soon as the obligation settles, allowing one pool to back a sequence of events. Conservation is enforced at every state transition.
Claim Families
Nine first-tier families compile into the same grammar, each through its own TemplatePack:
- Fixed income
- Equity and revenue share
- Structured derivatives
- Insurance and reinsurance
- Sharia-compliant instruments
- Real-world assets
- Event and parimutuel claims
- Loyalty and engagement
- Intellectual-property royalties
Each pack supplies the authority, evidence, risk, settlement, dispute, recovery, and reliance rules its family requires.
A block can settle a Sharia-compliant sukuk and a non-compliant parimutuel contract at the same time. Admission rules apply to each instrument and holder, allowing the venue to handle both.
Mass mints and governs claims through entity formation, legal authority, jurisdictional state, compliance composition, and rulebook authoring. Moxie clears them through pricing, matching, risk reservation, settlement, receipts, release and recovery, and reliance binding. A market cannot rewrite the entity or jurisdictional facts that make a claim valid. The jurisdictional system does not run a market maker. The admitted transition connects the two systems: Mass supplies authority and rule state, while Moxie supplies execution, reservation, settlement, and evidence of the result.
Operators build their own interfaces: fan applications, institutional terminals, or treasury consoles. These share one settlement asset hub, risk model, evidence grammar, and reliance envelope. A nineteen-year-old entering a prediction and an institutional risk officer margining a book use the same underlying system without seeing it.
Implementation and Legal Reliance
The system is built, and one clearing grammar admits every claim family. Its composition of compliance across all 23 regulatory domains is rigorously verified, with the strictest applicable rule taking precedence. It dispatches five certified pricing mechanisms by claim family inside consensus. They include batch auctions for pooled contingent claims, request-for-quote for bilateral institutional flow, and order books for high-frequency families.
The bound research suite is canonical for the mathematics. Each formal claim has a matching test, and specification and implementation remain synchronized. A multi-node testnet produces blocks through the MoxieBFT pipeline described above. Code connects the clearing and sovereign issuance systems, checking every state-changing transaction for compliance before it reaches the order book.
Legal reliance on a common receipt is harder than the engineering. Each participant must be able to rely on it for its named legal purpose. That includes an institutional bond trustee, a sukuk Sharia supervisory board, an insurance reinsurer, a parimutuel operator, an intellectual-property rights-holder, and a sports prediction market. One system must serve them all with a shared settlement asset hub, risk model, evidence grammar, and reliance envelope.
The Market
Moxie’s peers span institutional clearing and settlement: central securities depositories, central counterparties, dematerialized-note registries, and regulated electronic trading platforms. They also include tokenized-real-world-asset platforms run by the largest banks and regulated DLT market infrastructures under CSDR. On-chain derivatives venues serve individual claim families on a single chain.
The first product family Moxie was built against is event-contingent markets — sports, parimutuel, prediction. This family demonstrates how the system handles the correlation, latency, and oracle conditions described earlier. The system clears them at consensus, with cross-margining across spot, prediction, liquidity, and ephemeral positions. Capital becomes available again between events.
The second is institutional fixed income, exemplified by sports-club senior-secured bonds distributed to qualified-investor LPs through a regulated pathway. The third is Sharia-compliant instruments. The Sharia coordinate of the 23-domain tensor governs admission for each instrument, so the rule applies per instrument rather than across the venue. The fourth is intellectual-property royalties, with revenue-linked notes and licensing options compiled into the same clearing grammar. Equity, derivatives, real-world-asset receivables, and parametric insurance follow as TemplatePack instances.
The goal is to clear claims under the combined admission requirements of sovereign jurisdictions. One system supplies the settlement asset hub, cross-margin regime, evidence grammar, reliance envelope, and strategic-pricing layer. The fan, trustee, Sharia supervisory board, reinsurer, LP, and institutional risk officer each use a different interface to that system.
Moxie is a Momentum company. We welcome institutional counterparties: trustees, custodians, regulators, reinsurers, leagues, exchanges, market-makers, and LPs. We also welcome engineers who want to clear claims across jurisdictions under one clearing grammar. Contact raeez@momentum.inc.