Documentation

Technical reference for the OMNIUM framework

Overview

OMNIUM is a meta-currency framework implementing “dimensional money” — currency as a multi-dimensional vector rather than a scalar. Each unit carries magnitude, temporality, locality, purpose, and reputation (provenance).

Core Concept
Ω = (m, T, L, P, R)

where:
  m = magnitude (quantity)
  T = temporal stratum (T0/T1/T2/T∞)
  L = locality set (communities)
  P = purpose set (intent channels)
  R = reputation (provenance chain)

The framework enables money to carry semantic information — to remember what it's for, where it belongs, and where it came from — while remaining fully liquid and interoperable.

Architecture

OMNIUM is organized into five logical layers, each handling a specific dimension:


┌─────────────────────────────────────────────────────────────────┐
│                         OMNIUM LEDGER                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │ Commons Pool │  │ Wallet Mgr   │  │ Conversion Engine    │  │
│  │              │  │              │  │                      │  │
│  │ mint/burn    │  │ balance      │  │ Ω' = Ω × f(Δdims)   │  │
│  │ supply       │  │ units        │  │                      │  │
│  └──────────────┘  └──────────────┘  └──────────────────────┘  │
│                                                                 │
├─────────────────────────────────────────────────────────────────┤
│                         FIVE LAYERS                             │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌───────────┐ │
│  │  Temporal   │ │   Local     │ │   Purpose   │ │ Reputation│ │
│  │             │ │             │ │             │ │           │ │
│  │ T0: -2%/yr  │ │ Entry: 1%   │ │ Add: free   │ │ Accretes  │ │
│  │ T1: stable  │ │ Exit: var   │ │ Remove: 3%  │ │ Strip: 5% │ │
│  │ T2: +3%/yr  │ │             │ │             │ │           │ │
│  │ T∞: +1.5%   │ │             │ │             │ │           │ │
│  └─────────────┘ └─────────────┘ └─────────────┘ └───────────┘ │
│                                                                 │
├─────────────────────────────────────────────────────────────────┤
│                      ECONOMICS LAYER                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │ DividendPool │  │CommunityFund │  │    ComputePool       │  │
│  │              │  │              │  │    (Bootstrap)       │  │
│  │ demurrage →  │  │ exit fees →  │  │                      │  │
│  │ dividends    │  │ community    │  │ external $ → mint Ω  │  │
│  └──────────────┘  └──────────────┘  └──────────────────────┘  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
            

Core Types

The fundamental data structures that power OMNIUM:

OmniumUnit
interface OmniumUnit {
  id: string;                    // Unique identifier
  magnitude: number;             // Quantity of value (0 to ∞)
  temporality: TemporalStratum;  // T0 | T1 | T2 | TInfinity
  locality: Set<string>;         // Community IDs (empty = global)
  purpose: Set<string>;          // Purpose channel IDs (empty = unrestricted)
  provenance: ProvenanceChain;   // Complete history
  createdAt: number;             // Creation timestamp
  lastTickAt: number;            // Last demurrage/dividend calculation
  lockedUntil?: number;          // Temporal lock expiration
  walletId: string;              // Current owner
}
TemporalStratum
enum TemporalStratum {
  T0 = 'T0',         // Immediate: -2%/year demurrage
  T1 = 'T1',         // Seasonal: stable, 1-year lock
  T2 = 'T2',         // Generational: +3%/year, 20-year lock
  TInfinity = 'T∞',  // Perpetual: +1.5%/year, forever locked
}
ProvenanceEntry
interface ProvenanceEntry {
  timestamp: number;
  type: ProvenanceType;  // Minted | Earned | Gifted | Invested | Inherited
  fromWallet?: string;
  toWallet?: string;
  amount: number;
  note?: string;
  transactionId: string;
}

Economics Layer

The economics layer handles the flow of value within the system. Fees and demurrage don't vanish — they flow to where they create the most value.

DividendPool

Mediates time preference by collecting T0 demurrage and distributing it as T2/T∞ dividends:

DividendPool Flow
T0 holder (decaying money)
    │
    ▼ demurrage collected
┌──────────────────┐
│   DividendPool   │ ← accumulates over time
└──────────────────┘
    │
    ▼ dividends distributed
T2/T∞ holders (growing money)

CommunityFund

Each community has its own fund, accumulating exit fees for local sovereignty:

CommunityFund API
// Deposit exit fees when money leaves a community
communityFunds.depositExitFee(
  communityId: string,
  amount: number,
  sourceUnitId: string,
  sourceWalletId: string,
  timestamp: number
)

// Communities can withdraw for local purposes
communityFunds.withdraw(communityId, amount, note)

Proof-of-Useful-Compute

The bootstrap mechanism for OMNIUM. External demand for computation creates real value, allowing the economy to start from zero without requiring initial capital.


External Requestor (needs simulation)
        │
        ▼  pays $
   ┌──────────────┐
   │ Commons Pool │ ← external value accumulates
   └──────────────┘
        │
        ▼  authorizes minting
   ┌──────────────┐
   │ ComputePool  │ ← manages job lifecycle
   └──────────────┘
        │
        ▼  verified work
   ┌──────────────┐
   │   Provider   │ ← receives freshly minted T0 Ω
   └──────────────┘
        │
        ▼  spends, time passes
   ┌──────────────┐
   │ Demurrage    │ → DividendPool → T2/T∞ yields
   └──────────────┘
            

Job Lifecycle

ComputePool Usage
// 1. External requestor submits a job
const job = ledger.submitComputeJob(
  'requestor-id',
  {
    type: 'simulation',
    payload: { climate: 'model-v2' },
    estimatedCompute: 1000,
    description: 'Climate simulation run'
  },
  100  // $100 payment
);

// 2. Provider claims the job
ledger.claimComputeJob(job.id, providerWallet.id);

// 3. Provider completes with proof
const result = ledger.completeComputeJob(job.id, providerWallet.id, {
  output: { temperature: 2.5, confidence: 0.95 },
  proof: {
    type: 'attestation',  // or 'redundant', 'tee', 'challenge'
    data: { signature: '...' },
    timestamp: Date.now()
  },
  actualCompute: 1000,
  executionTime: 5000
});

// Provider now has 100 Ω in their wallet!

Proof Types

  • Attestation — Provider self-attests (trust-based, suitable for bootstrap phase)
  • Redundant — Multiple providers run the same job, results must match
  • TEE — Trusted Execution Environment provides hardware attestation
  • Challenge — Optimistic execution with fraud proofs during challenge period

Simulation Framework

The deeper model of Proof-of-Useful-Compute centers on verified emergence: value comes from emergent properties that arise from following simulation rules correctly.

Core Concept

Payment is not for CPU cycles — it's for verified emergence. The blockchain becomes an immutable ledger proving the history of computed jobs.

LawSet (Content-Addressed Rules)
interface LawSet {
  id: string;
  name: string;
  domain: 'physics' | 'economics' | 'biology' | 'chemistry' | 'social' | 'custom';
  rulesCid: string;      // Content-addressed rule package
  invariants: string[];  // e.g., ['energy-conservation', 'mass-conservation']
  version: string;
}
DeterministicContainer
interface DeterministicContainer {
  id: string;
  name: string;
  runtime: 'wasm' | 'docker' | 'native';
  imageCid: string;
  determinismProperties: {
    networkIsolated: boolean;
    filesystemIsolated: boolean;
    deterministicRandom: boolean;
    fixedClock: boolean;
  };
}

Emergent Properties

These are the actual valuable outputs of simulations:

  • Metric — Quantitative measurements (temperature, population, etc.)
  • Pattern — Recurring structures or behaviors
  • PhaseTransition — Qualitative state changes
  • Equilibrium — Stable states the system settles into
  • Prediction — Forecasts for future states
  • Anomaly — Unexpected behaviors worth investigating
ReproducibilityProof
interface ReproducibilityProof {
  method: 'self-attestation' | 'consensus' | 'tee' | 'zk-proof';

  reproductionRecipe: {
    lawSetCid: string;
    containerCid: string;
    initialStateCid: string;
    finalStateCid: string;
    stepsExecuted: number;
  };

  attestations: Array<{
    providerId: string;
    signature: string;
    computedFinalStateCid: string;
  }>;
}

Getting Started

Installation
# Clone the repository
git clone https://github.com/idl3o/omnium.git

# Navigate to the omnium package
cd omnium

# Install dependencies
npm install

# Run tests
npm test

# Build
npm run build
Basic Usage
import { createLedger } from './engine/ledger.js';

// Create a new ledger
const ledger = createLedger();

// Create wallets
const alice = ledger.wallets.createWallet('Alice');
const bob = ledger.wallets.createWallet('Bob');

// Mint some Ω
const unit = ledger.mint(1000, alice.id, 'Initial funding');

// Transfer
ledger.transfer(unit.id, bob.id, 500, 'Payment for services');

// Convert temporal stratum
ledger.convert(unit.id, { targetTemporality: 'T2' });

// Advance time (apply demurrage/dividends)
ledger.tick(30);  // 30 days

// Check status
console.log(ledger.status());

API Reference

Ledger Methods

mint(amount, walletId, note?)

Create new T0 Ω from the Commons Pool

transfer(unitId, toWalletId, amount?, note?)

Transfer Ω between wallets, updating provenance

convert(unitId, options)

Convert dimensions: temporality, locality, purpose

tick(days)

Advance time, applying demurrage to T0 and dividends to T2/T∞

submitComputeJob(requestor, spec, payment, options?)

Submit a compute job for providers to claim

claimComputeJob(jobId, providerId)

Provider claims a pending job

completeComputeJob(jobId, providerId, result)

Submit completed work with proof; auto-mints reward on success