Obelyth

Obelyth is a blockchain network that replaces purposeless hash-grinding with verifiable AI compute work — while maintaining Bitcoin's core monetary guarantees.

Where Bitcoin miners burn energy solving arbitrary puzzles, Obelyth miners earn OBY tokens by completing real tasks: running AI inference jobs, fine-tuning language models, and generating embeddings for paying developers. Every unit of compute sold by the network flows 90% into a USDC liquidity reserve that continuously deepens the OBY liquidity reserve.

The result is a compute settlement token with deep protocol-managed liquidity, and a compute marketplace that undercuts Amazon Web Services by approximately 56% at launch.

Two industries are broken in the same way: crypto mining wastes energy on nothing, and AI compute is monopolized by three cloud providers extracting 60–70% margins.

Bitcoin mining consumes electricity equivalent to mid-sized nations to produce security — and nothing else. The computation that secures the network has zero utility outside the network. This is a feature Bitcoin's designers chose deliberately, but it is an enormous waste when useful computation could secure the network instead.

AI compute costs are dominated by AWS, Google Cloud, and Azure. A single NVIDIA A100 GPU-hour costs $3.21 on AWS. The actual hardware cost to the provider is a fraction of that. Developers building AI applications have no alternative except to pay monopoly pricing or invest millions in their own hardware.

Solving these problems together requires solving four technical challenges that have defeated prior attempts: the latency problem, the verification dilemma, the developer experience gap, and the supply bootstrapping problem. Obelyth's architecture addresses each specifically.

Obelyth is built with five architectural innovations over Bitcoin's base design, each solving a specific known limitation.

Obelyth miners do not guess hashes. They run AI jobs. The work is useful. The verification is real. The economics are aligned.

Scope of work. At launch, Obelyth targets inference and fine-tuning — not foundational model training. This is a deliberate choice. Training a GPT-4 scale model requires petabytes of inter-GPU communication between thousands of coordinated nodes. That is incompatible with decentralized geography. Inference and fine-tuning require one to eight GPUs per job with minimal cross-node communication — a perfect fit for independent miners worldwide.

The verification solution. Verifying that a miner actually ran an AI job — rather than faking the result — is the fundamental challenge of PoUW. Obelyth uses optimistic verification with random challenge audits:

When a miner completes a job, the result is accepted optimistically. A random subset of validators re-run a small portion of the work. If a challenge is raised and the miner's result does not match, 20% of their staked OBY is slashed. The probability of challenge scales with miner reputation across three tiers:

Planned escalating consequences for fraud. The following mechanics are being finalised during testnet. First offence: 20% stake slash and reputation reset to zero, returning the miner to 30% challenge rate. Second offence: 50% stake slash and a time-locked ban from the network. The developer whose job was faked receives a full refund funded automatically from the slashed stake. Repeated fraud burns through stake faster than any possible gain from faking jobs, making fraud economically irrational. These parameters will be stress-tested against real adversarial conditions during testnet before mainnet launch.

Long-term: ZK proof verification. Optimistic verification is the pragmatic starting point — ZK proofs of inference are the destination. EZKL and Risc Zero can generate cryptographic proofs that a specific model ran a specific input and produced a specific output, making fraud mathematically impossible rather than economically discouraged. Current ZK proof generation overhead is 100x-1000x the cost of running the inference itself, making it too slow for production workloads at launch. This changes as the technology matures. ZK verification is on the roadmap at Month 12-18 and requires a DAO governance vote before implementation.

The future path is ZK proofs (EZKL, Risc Zero) that mathematically prove correct execution without re-running the work at all. The infrastructure is stubbed in the codebase and will replace random audits in the Rust production node.

Developer experience. An AI engineer should not need to understand blockchain mechanics to use Obelyth. The SDK reduces integration to two lines of code:

# BEFORE — runs on local GPU or AWS
from transformers import pipeline
pipe = pipeline('text-generation', model='meta-llama/Llama-3-8B')

# AFTER — runs on Obelyth (two lines changed)
from transformers import pipeline
from obelyth import ObelythClient                          # ← line 1
pipe = ObelythClient(api_key='oby_...').pipeline(        # ← line 2
           'text-generation', model='meta-llama/Llama-3-8B')

# Everything else identical
result = pipe("Explain quantum computing")[0]
print(result.generated_text)

OBY has a hard cap of 21,000,000 tokens. Miners earn OBY. Developers pay USDC. The two are connected by the AMM and the liquidity reserve.

Miners earn OBY only. No USDC flows directly to miners. Instead, the USDC paid by developers builds the liquidity reserve, which backs the value of the OBY miners earn. This is the correct economic design: miner incentives are denominated in the native token, and that token's value is structurally supported by real demand.

Block rewards follow Bitcoin's halving schedule. The initial reward is 50 OBY per block (100 OBY during the bootstrap year), halving every 210,000 blocks. Miners also earn OBY-denominated compute rewards for completing AI jobs, creating a second income stream that grows as network usage grows.

Burn policy. Obelyth does not burn OBY by default. Premature burning reduces the liquidity available to miners and users during the critical bootstrapping phase. The DAO may vote to allocate some or all of its 5% slice to buy and burn OBY once the network reaches sufficient maturity. This decision requires an explicit governance vote — it is never automatic.

DAO Mining Tax. 5% of all OBY earned by miners — both block rewards and compute job rewards — is automatically redirected to the DAO vault before the miner receives their payment. This is enforced at the consensus layer: a coinbase transaction that does not include the correct DAO vault output will be rejected by every node. The vault accumulates OBY natively; governance decides how to deploy it — additional liquidity, grants, burn, or hold. This gives the DAO two fully independent income streams: stablecoin fees from developers, and OBY from miners.

Bootstrap subsidy. Block rewards are doubled (2×) during the first year of operation, tapering linearly back to the base rate over 52,560 blocks (~one year). This directly addresses the supply-side bootstrapping problem: miners are heavily incentivized to bring GPUs online before developer demand exists.

Before OBY is listed on any external exchange, users can buy and sell OBY directly through Obelyth's internal constant-product AMM. This is the only on-ramp at launch.

Constant-product formula. The AMM maintains the invariant usdc_reserve × oby_reserve = k. As USDC enters (buy pressure), OBY price rises. As OBY is sold, price falls. Ninety percent of every developer fee automatically deepens the USDC side of the pool, permanently raising the liquidity depth.

The liquidity depth is protocol-enforced, not managed by any party. No one decides when to intervene. As developer fees accumulate in the pool, the minimum price at which any amount of OBY can be sold rises continuously. At $1M in fees processed, the pool contains $900,000 in USDC. That USDC deepens the pool continuously, supporting orderly price discovery.

0.3% swap fee. Every buy and sell carries a 0.3% fee that remains inside the pool, further compounding liquidity depth over time.

Exchange listings. When OBY is listed on external exchanges, the internal AMM continues to operate. The USDC reserve creates a credible arbitrage floor — if OBY trades below the internal AMM price on an external exchange, arbitrageurs will buy external and sell internal, pushing prices back into alignment.

Obelyth accepts USDC, DAI, USDT, and EURC. The 90% liquidity reserve holds all four according to target weights, hedging against any single stablecoin failing or being frozen.

If USDC depegs to $0.87 (as it briefly did in March 2023), only 40% of the Obelyth reserve is affected — not 100%. The reserve loses roughly 5% of total value rather than 13%. DAI's 35% share provides the most important hedge: it has no freeze function, meaning no government or regulator can block access to those funds.

Obelyth launches under founder control and transitions to community governance on a published timeline. The hard cap, fee split, and liquidity lock are not subject to governance.

Constitutional parameters — the 21M supply cap, the 90% liquidity lock, and the USDC-only fee denomination — are encoded at the protocol level. They require a 90% supermajority to change, a threshold deliberately set above any realistic coalition. In practice these parameters are immutable.

Phase 1: Multisig (Launch – Month 12). The DAO fund is controlled by a founder multisig. All allocations are publicly disclosed. The DAO can allocate its 5% to: additional liquidity, ecosystem grants, audits, or burn. No decisions affect the 90% liquidity lock.

Phase 2: Token-weighted governance (Month 12+). OBY holders vote on DAO fund allocations, protocol parameter changes (block size targets, difficulty windows), and grant proposals. A NIP (Obelyth Improvement Proposal) process governs upgrades: signal vote → 90-day testnet → gradual mainnet activation at 95% node readiness.

Fork prevention. Every transaction is cryptographically bound to the canonical chain ID. Replay protection makes maintaining a competing fork economically non-viable. An on-chain treasury funds development via grants, eliminating the corporate sponsor conflicts that caused historical Bitcoin forks.

The DAO governs. The OpCo executes. This separation protects token holders, enables legal compliance, and allows the protocol to operate in the real world without compromising on-chain sovereignty.

Why the DAO needs an OpCo. A DAO is not a legal person in most jurisdictions. It cannot sign contracts, employ staff, hold bank accounts, pay taxes, or transact in fiat currency. The Operations Company is the legal wrapper — a Cayman Foundation Company — that can do all of these things on behalf of the DAO.

What the OpCo handles. The OpCo employs the steering committee and protocol staff with a combination of USD salary and vesting OBY compensation. It holds the DAO stablecoin fund in a regulated multi-sig wallet, executes settlement distributions, signs contracts with exchanges and legal firms, files tax returns, and handles KYC/AML compliance. Every expenditure above $50,000 requires a passed DAO governance vote before the OpCo can execute it.

Multi-sig treasury control. All OpCo treasury movements require 3-of-5 steering committee member signatures. No single person can move funds unilaterally — not the founder, not any committee member. This is enforced at the wallet level, not just by policy.

DAO sovereignty preserved. The DAO can replace the OpCo via governance vote at any time. If the OpCo ever acts against DAO interests, governance removes it and designates a new legal entity. The OpCo serves at the DAO's pleasure, never the reverse.

OBY token allocation. The founder retains 3% of the total OBY supply (630,000 OBY) subject to a mandatory vesting schedule enforced at the protocol consensus layer:

Vesting is enforced by consensus — a transaction spending unvested founder OBY will be rejected by all nodes. The vesting schedule cannot be modified by any governance vote. The founder wallet address and vested/locked amounts are queryable in real time via the /vesting RPC endpoint.

Creator Share (Protocol Fee). The founder receives a permanent 5% protocol fee on all USDC compute fees. This is a constitutional parameter defined in the Foundation charter — it is not subject to DAO governance and cannot be modified or removed by any vote. It is labelled "Creator Share" in public materials and "Protocol Fee" in legal documents. The /creator RPC endpoint publicly shows the balance and lifetime disbursements in real time.

No other interests. The founder holds no other economic interest in the protocol beyond the above. The 90% liquidity reserve is not accessible to the founder. The DAO multisig (initially founder-controlled) transitions to on-chain governance at Month 12.

Rust sequencing — the honest commitment. The Rust production node begins development in Month 1-2, runs in parallel with the Python reference node during testnet, and becomes the primary node before mainnet launches. Mainnet will not launch until the Rust node has run as primary on testnet for at least 60 consecutive days. This is more conservative than most projects publish — and more credible.

Obelyth is four layers working as one product. From the developer's perspective it is two lines of code and a USDC payment. Everything else — verification, privacy, economic settlement, governance — is invisible infrastructure.

The Four-Layer Stack

┌─────────────────────────────────────────────────────────┐
│                    DEVELOPER LAYER                       │
│          ObelythClient SDK — two lines of code           │
│          Pays in USDC / DAI / USDT / EURC               │
│          Chooses job tier via single parameter           │
└──────────────────────────┬──────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────┐
│                    PROTOCOL LAYER                        │
│      Job routing, verification, result aggregation       │
│      AMM liquidity reserve, fee split enforcement        │
│      Governance, DAO vault, reputation system            │
└──────────────────────────┬──────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────┐
│                    COMPUTE LAYER                         │
│   Standard │ Redundant Parallel │ Pipeline │ TEE │ ZK   │
│       vLLM execution, shard routing, attestation         │
│         Stake-weighted miner selection                   │
└──────────────────────────┬──────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────┐
│                   SETTLEMENT LAYER                       │
│         Base chain — ~$0.001 per transaction             │
│         Multicall3 batch settlement windows              │
│         On-chain attestation registry                    │
│         AMM smart contract — 90% liquidity lock          │
└─────────────────────────────────────────────────────────┘

How a Job Flows Through the System

Step 1 — Developer submits via SDK. The developer calls the SDK with a prompt, model name, and optional tier parameter. The SDK encrypts the prompt using ECDH session key exchange, attaches the job specification — model, token count, hardware tier required, execution tier — and submits to the nearest node. The developer never interacts with the blockchain directly.

Step 2 — Node routes the job. The node selects miners using stake-weighted randomness. Standard jobs go to one miner. Redundant parallel goes to three. Private jobs route only to attestation-verified miners. Pipeline parallel routes to a geographically proximate miner group. The node routes the encrypted job without ever seeing the plaintext prompt.

Step 3 — Miners execute. Miners receive the job, decrypt with the session key, run inference via vLLM, and return results with a cryptographic hash of the input and output. For redundant parallel, three miners return independently — agreement means all three are paid, divergence immediately identifies the outlier and triggers slashing. For pipeline parallel, miners pass intermediate activations sequentially — no single miner sees both the full input and output.

Step 4 — Fee settlement. Job cost is deducted from the developer's internal balance. The 90/5/5 split executes — 90% queued for AMM deposit, 5% to Creator Share, 5% to DAO fund. Miner payment is issued minus the 5% DAO mining tax on OBY earnings. All settlement is batched via Multicall3 on Base chain once per settlement window. On-chain record contains only job IDs, hashes, and payment amounts — never prompt content.

Step 5 — Developer receives result. The SDK decrypts the result and returns it to the developer's application. From the developer's perspective it is identical to calling a HuggingFace pipeline. The entire protocol stack is invisible.

The Four Job Tiers

ZK verification is available across tiers for models under 1B parameters at mainnet launch. Adding zk=True to any job generates a Groth16 proof of correct execution verifiable on Base chain. ZK for larger models targets Month 18–36 as EZKL and Risc Zero reduce proof generation overhead.

How Privacy, Verification, and Performance Converge

These are not three separate features — they are the same architectural decision viewed from three angles. Multi-miner execution improves all three simultaneously. Redundant parallel improves verification and reliability without privacy. Pipeline parallel improves all three — faster through parallelism, verifiable through shard checking, private through input fragmentation. TEE adds hardware attestation on top of any execution model. The full combination — pipeline parallel inside TEE enclaves with ZK proof output — is the strongest possible configuration and the long-term enterprise target.

How the Economic Model Ties Everything Together

Every job at every tier feeds the same economic engine. Developer pays stablecoins. 90% of that payment continuously deepens the AMM liquidity reserve — a value that never decreases regardless of market conditions. Miners earn OBY and have a direct incentive to bring in more developer volume because more volume deepens the reserve, which supports OBY liquidity, which makes their earnings worth more. Incentives between miners and developers point in the same direction.

The 5% DAO mining tax accumulates OBY in the vault automatically. This funds the bug bounty, ZK upgrades, governance proposals, and eventually exchange listing liquidity — all without requiring governance action to maintain.

Honest Gaps — What Is Not Yet Built

These gaps are documented here because informed participants make better decisions than surprised ones. Every item on this list has a clear implementation path and a defined place in the roadmap. None requires fundamental redesign. The Python reference node proves the protocol logic is correct. The build sequence exists to add production-grade features in a logical order without compromising what already works.

No existing decentralized compute network has a production privacy tier. Over 70% of enterprise AI workloads will involve sensitive data by 2026. Obelyth addresses this with a two-tier privacy architecture available at launch.

Why Privacy Matters for Decentralized Inference

In Obelyth's standard inference model, developers submit jobs to GPU miners who execute them. The assigned miner sees the prompt during execution. For the majority of AI workloads — open source models, public data, content generation, coding assistance — this presents no privacy concern. It is equivalent to the trust model of any cloud GPU provider.

For enterprise workloads involving sensitive data — medical records, legal documents, financial data, proprietary business information — sending raw prompts to anonymous GPU operators is unacceptable. Banking, healthcare, legal, and government customers cannot participate in a network without a credible privacy answer. The confidential computing market was $5.59 billion in 2025, growing at 16.29% annually, driven specifically by this demand.

Two-Tier Architecture

Standard Tier — What the Protection Actually Means

Transport encryption. TLS 1.3 between every party. Developer to node to miner to node to developer. No passive observer can read prompts off the wire.

ECDH per-job key exchange. Developer generates a session keypair. Prompt is encrypted before submission. Only the assigned miner receives the session key. The node routes the encrypted job without seeing plaintext. Session key is destroyed after job completion.

Sandboxed execution. Miner daemon runs inside a Docker container with no persistent storage, no network egress except back to the node, and no access to the host filesystem. Memory is wiped after each job. The container is destroyed. Audit logs contain only job IDs, timestamps, and cryptographic hashes — never plaintext.

Blind job routing. Miners never know who the developer is. Developer address is hashed before inclusion in the job specification. The miner sees a job ID, model name, and encrypted prompt — not the developer's identity.

Economic disincentives. Miners stake OBY to participate. A miner who leaks developer data and is caught loses 50% of stake plus a permanent network ban. With significant stake requirements, data leakage is economically irrational.

Honest limitation. The assigned miner still sees the prompt in plaintext during execution. This is the same trust model as AWS, Google Cloud, and Azure — employees theoretically have access to data in use. It is appropriate for workloads where developers accept cloud-equivalent trust. It is not appropriate for workloads that require cryptographic privacy. For those, the TEE tier is the answer.

Private Tier — TEE Attestation

Trusted Execution Environments create hardware-isolated enclaves where even the host operating system cannot read memory contents. Two hardware options are supported:

AMD SEV-SNP (AMD EPYC CPUs) — encrypts virtual machine memory at the hardware level. Available on any server with a modern AMD EPYC processor plus any NVIDIA GPU. More accessible than H100-only approaches — significantly broader miner pool.

NVIDIA H100 Confidential Computing — production-ready TEE for GPU workloads. Available on all major cloud providers. Performance overhead under 5% of native speed. The miner's GPU cannot access decrypted model inputs. Remote attestation is cryptographically verifiable.

Developers opt into the private tier with a single SDK parameter:

# Standard inference — default
pipe = ObelythClient(api_key="oby_...").pipeline(
    "text-generation", model="meta-llama/Llama-3-8B"
)

# Private inference — TEE attested, one parameter change
pipe = ObelythClient(api_key="oby_...").pipeline(
    "text-generation", model="meta-llama/Llama-3-8B",
    privacy=True
)

The SDK handles miner selection, attestation verification, and key exchange automatically. No developer knowledge of hardware security required.

ZK Verification at Launch

ZK proofs of inference via EZKL are available at mainnet launch for models under 1B parameters. EZKL generates a Groth16 proof that a specific model with specific weights processed a specific input and produced a specific output. The proof is verified on Base chain. This makes fraud mathematically impossible rather than economically discouraged — and eliminates the divergence tolerance problem entirely for supported model sizes.

For larger models (7B+), current ZK proof generation overhead runs at 100x-1000x the inference cost itself, making it too slow for production use today. As EZKL and Risc Zero reduce this overhead, larger model ZK verification will be added. This is on the roadmap at Month 18-36 and requires a DAO governance vote before deployment.

Market Context

60% of enterprises are evaluating TEE for production AI workloads in 2025. Cyber insurance providers are beginning to mandate TEE for sensitive workloads. The $5.59 billion confidential computing market is growing at 16.29% annually, expected to reach $16.09 billion by 2032. IBM Research is actively working on confidential inference via vLLM with H100 Confidential Computing. Red Hat's Office of the CTO is building cloud-native confidential AI infrastructure.

No existing decentralized compute network — Akash, Render, io.net, Gensyn — has a production privacy tier. This is Obelyth's most significant enterprise differentiator and a direct response to a documented market need.

Informational purposes only. This document is provided for informational and technical discussion purposes only. It describes a protocol under active development. The architecture, tokenomics, governance model, and roadmap described herein are subject to change without notice. Nothing herein constitutes a binding commitment by the Obelyth Protocol Foundation or its founders.

No guarantee of performance. Obelyth is experimental software. There is no guarantee that the network will operate as described, achieve the milestones set out in this document, or that OBY will have any particular value or utility. Participants in the testnet acknowledge that testnet OBY tokens have no monetary value and confer no rights or entitlements of any kind.

Regulatory uncertainty. The regulatory treatment of blockchain protocols, utility tokens, decentralized exchanges, and stablecoin payment systems varies significantly across jurisdictions and continues to evolve. The Obelyth Protocol Foundation intends to obtain legal guidance — including a securities classification opinion and AMM regulatory review — prior to mainnet launch and prior to accepting real USDC payments. Nothing in this whitepaper should be interpreted as a legal opinion on the status of OBY under the laws of any jurisdiction.

U.S. persons. This whitepaper is not directed at persons in the United States of America. Residents of the United States should not rely on this document in connection with any decision relating to OBY or the Obelyth network. Obelyth will not actively target U.S. persons for participation until applicable legal and regulatory requirements have been assessed and addressed by qualified U.S. counsel.

Forward-looking statements. This document contains forward-looking statements, including statements about the technical capabilities, launch timelines, economic model, and governance structure of the Obelyth protocol. These statements are based on current expectations and assumptions and involve known and unknown risks and uncertainties. Actual results may differ materially from those expressed or implied.

Intellectual property. Obelyth, OBY, and the Obelyth emblem are unregistered trademarks of the Obelyth Protocol Foundation. The Obelyth codebase is released under the MIT License. Nothing in this document grants any license to any third party to use the Obelyth name, logo, or brand assets.

Obelyth Technical Whitepaper v1.0 — Pre-Testnet Release
© 2025 Obelyth Protocol Foundation. All rights reserved.
Not an offer of securities. Not financial advice. Consult qualified legal counsel before participating.