Skip to main content

Implementation Rationale (2026)

This page summarizes major protocol integration work completed in 2026 and the rationale behind key decisions.

Scope delivered​

Across the protocol program, SDK, oracle service, and operator frontend:

  1. Protocol v2 lifecycle and module support was implemented in code paths used by operators:
    • pool policy and quorum configuration
    • outcome schema + rule registration
    • rewards claim lifecycle extensions
    • coverage policy and policy-NFT linkage
  2. SDK v2 coverage was expanded:
    • deterministic builders for v2 instructions
    • readers for v2 account types
    • seed-safe validation and deterministic encoding behavior
  3. Oracle service was hardened for production claim lifecycle reliability:
    • strict prepared-intent message binding
    • reclaimable idempotency leases
    • typed failure code surfaces and reconcile path
    • on-chain state as source of truth for protocol outcomes
  4. Protocol frontend operator flows were expanded:
    • schema/rule authoring
    • pool oracle policy controls
    • coverage policy setup actions

Key design decisions and why​

1) Intent-bound claims​

  • Decision: signed claim tx must match the exact prepared unsigned intent message.
  • Why: prevents claim payload substitution attacks where a valid signature is replayed on a different message.

2) Deterministic preparation and ordering​

  • Decision: stable ordering for outcome and attestation-derived claim preparation inputs.
  • Why: ensures replay-safe idempotency and reproducible debug/test behavior regardless of datastore iteration order.

3) Reclaimable idempotency leases​

  • Decision: attestation processing uses expiring pending leases with explicit terminal states.
  • Why: prevents indefinite pending records after partial failures and enables safe retry/recovery.

4) Quorum-first attestation path with fallback​

  • Decision: prefer v2 quorum vote + finalize; retain legacy path for older SDK snapshots.
  • Why: allows migration without breaking deployed services while moving canonical flow to quorum-based settlement.

5) Firestore boundary​

  • Decision: Firestore is operational metadata only; protocol truth is always read from on-chain accounts.
  • Why: avoids state divergence and preserves an open, permissionless protocol model.

6) Operator-first frontend​

  • Decision: protocol frontend exposes setup controls directly (policy/schemas/coverage), not hidden behind backend-only tooling.
  • Why: keeps protocol operation open to non-OmegaX operators and reduces hidden prerequisites for pool launches.

Trust model (explicit)​

  • Oracle backends sign outcome attestations.
  • Claimant wallet (or authorized delegate) signs reward claim movement.
  • Backend broadcasts signed claims and tracks finality; it does not custodially sign user reward transfers in v1.

Verification (high level)​

  • Unit and integration testing across the SDK, oracle service, and operator frontend.
  • End-to-end flows validated against on-chain state as the source of truth.
Download PDF