Genesis Protocol — Whitepaper

Version 0.1 (Draft) · 2026-09-06 · Phantom Workz LLC · Author: xLAWLESSx

Genesis Protocol — the first Layer 1 where trust is scored, staked, insured, and compounding.

Status: draft for internal design use. Token parameters describe protocol mechanics, not an offering. Genesis Protocol tokens are not yet available. Nothing in this document is an offer of securities.

---

1. Abstract

Genesis Protocol is a modular, intent-centric Layer 1 blockchain that treats trust as a first-class, measurable, on-chain asset. It combines proof-of-stake consensus with deterministic single-block finality, a multi-token economy with programmatic fee burning, a Work Provisioning layer that turns real computation into on-chain value, an agent framework where automated actors operate under certified, liability-bound identities, and Genesis Score — a portable, on-chain reputation metric.

The protocol's core thesis: blockchains secured the transfer of value but never priced the trustworthiness of participants. Genesis closes that gap. Behavior — validating honestly, completing work, repaying loans, governing responsibly — is observed on-chain, scored, and made economically consequential. Good actors compound advantage; bad actors are slashed, scored down, and priced out.

This paper describes the protocol's architecture, economics, and roadmap from devnet to mainnet.

---

2. Introduction: the trust problem

2.1 What blockchains solved — and what they didn't

Bitcoin proved that value can move without intermediaries. Ethereum proved that agreements can execute without intermediaries. Cosmos proved that sovereign chains can interoperate without intermediaries. But none of them answered a simpler question: whom should you trust, and how much?

Today, every chain treats a first-time address and a five-year honest validator as identical inputs. Lending requires overcollateralization because protocols cannot distinguish reliable borrowers from anonymous ones. Computation marketplaces cannot distinguish capable workers from sybils. MEV extractors exploit users because transaction intent is public by default. The result is an ecosystem that overpays for security (locked collateral, redundant trust assumptions) while underpricing the one thing that would make it efficient: information about behavior.

2.2 Why existing fixes fall short

• Off-chain credit scores reintroduce the intermediaries blockchains removed, and they cannot be verified trustlessly.
• Soulbound credentials record claims, not behavior, and rarely carry economic consequence.
• Overcollateralization works but locks up productive capital — a tax on every honest participant to cover the dishonest few.
• Centralized compute marketplaces (AWS, and their crypto equivalents with trusted coordinators) recreate single points of failure and rent extraction.

2.3 The Genesis answer

Genesis Protocol makes trust scored (Genesis Score observes behavior on-chain), staked (validators, workers, and agents all post economic security), insured (slashing, insurance fund, and circuit breakers bound the downside), and compounding (good behavior raises scores, unlocks better terms, and earns more — a flywheel, not a snapshot).

---

2.4 What Genesis is not

Genesis is not a privacy coin: PRIV rewards privacy-layer work, but the chain itself is transparent and compliance proofs are mandatory. It is not an L2 or app-chain renting security: sovereignty - own validator set, own finality, own upgrades - is the point. It is not a "faster EVM": EVM compatibility is an execution option, not the identity; the differentiators (work, agents, score) live in native modules. It is not AI-governed: no model ever votes, proposes blocks, or sets scores - agents execute certified code under human-liable operators. And it is not a fair-launch experiment: supply schedules, fee splits, and treasury flows are declared up front and changeable only through governance.

2.5 The cost of distrust

Distrust is the largest hidden tax in crypto. Overcollateralized lending routinely demands 130-200% collateral, locking productive capital to insure against anonymous borrowers. MEV - value extracted by reordering or sandwiching users' public transactions - functions as an invisible fee on every trade. Compute marketplaces either centralize (reintroducing the intermediary) or accept sybil workers they cannot punish. Each workaround concedes the same point: without information about behavior, protocols must assume the worst participant and charge everyone accordingly.

Genesis inverts the assumption. When behavior is observed, scored, and economically consequential, the honest majority stops subsidizing the dishonest minority. Collateral requirements can fall because scores predict repayment. MEV disappears for intents that stay private until settlement. Workers can be paid on delivery because verification and slashing make cheating unprofitable. The protocol's job is to make the honest strategy the highest-yielding one - and then let competition do the rest.

3. Design principles

1. Deterministic finality. No probabilistic confirmations. A committed block is final — full stop. This is a consensus property (CometBFT) and a product pillar: exchanges, wallets, and agents can act on single-block confirmation.
2. Modularity over monoliths. Consensus, execution, work, reputation, and agency are separate layers with explicit interfaces. Each can evolve without hard-forking the others' logic.
3. Both execution worlds. EVM compatibility captures the largest existing developer ecosystem; CosmWasm captures native, governance-grade chain logic. Genesis runs both rather than choosing.
4. Economics before incentives theater. Every emission has a sink. The flagship mechanism — programmatic fee burning with cross-module sinks — means protocol usage mechanically strengthens the gas coin (GENX).
5. Agents are citizens, not scripts. Automated actors hold certified on-chain identities, stake, permissions, and liability. Their actions are logged, auditable, and co-signed where irreversible.
6. No LLM inside the protocol. Consensus, execution, and scoring are deterministic software. Agents run certified, hash-committed builds — the chain verifies what code acted, never what a model decided.
7. Compliance by architecture. Privacy layers ship with compliance proofs; the agent registry binds liability to operators; token launch follows audits and legal review — never precedes them.

---

4. System overview

Genesis is a sovereign Layer 1 built on the Cosmos SDK (v0.50.x) with CometBFT consensus. Block time targets 2 seconds on devnet, 1 second at mainnet. The system has six layers:

Users touch the system through the browser wallet (and later mobile), the block explorer, and the Workbench. Validators run genesisd (operated via the genesisctl wrapper). Agents interact through the same RPC and transaction interfaces as humans — with certified identities attached.

---

4.1 How the layers interact

A transaction's journey crosses every layer. A wallet signs an intent or transaction and submits it to a node mempool; CometBFT orders it into a block with deterministic finality; the relevant modules execute (fees split by x/feeburn, work orders escrowed by x/work, scores updated by x/gscore); emitted events stream to the indexer and surface in the explorer within seconds. A work order's journey is longer: posted on-chain, committed by a staked worker, executed off-chain in the Workbench, submitted with proof, verified by ladder, settled with the protocol fee routed to burn - and the worker's reputation updated for the next round. An agent's journey is the most constrained: every action checked against registered permissions and build hash, co-signed when irreversible, logged in a hash chain whose root lands on-chain daily. Each layer trusts the others only through these explicit, checkable interfaces.

4.2 Two runtimes, one state

The EVM layer captures the existing world: developers, wallets (MetaMask), tooling (Foundry), and the ERC-20 standard. CosmWasm captures native chain logic with strong typing and governance-grade upgrade paths - the natural home for the agent registry and modules that must reason about chain state directly. Both execute against the same underlying state; ERC-20 predeploys make native denominations visible to EVM contracts, and precompiles expose native modules (staking, work escrow, score queries) back to EVM code. The exact precompile set and cross-runtime call rules are specified in ARCHITECTURE.md - the principle here is that developers meet Genesis where they already are, while protocol-critical logic stays in the runtime built for it.

4.3 Who does what

5. Consensus and finality

5.1 CometBFT proof-of-stake

Genesis inherits battle-tested BFT consensus: a known validator set, round based proposing and voting, and finality when two-thirds of voting power pre-commits. There are no reorgs of committed blocks and no confirmation counting. Parameters:

• Maximum validators: 100
• Unbonding time: 21 days
• Minimum self-delegation: 1000 GEN
• Downtime slashing: 0.01% plus 10-minute jailing
• Double-sign slashing: 5% plus tombstoning (permanent removal)

Governance (devnet values; mainnet values set by governance at launch): voting period 72 hours, minimum deposit 100 GEN.

5.2 Why finality is the product

Single-block finality compresses every downstream design: the explorer shows settled state, never "pending"; intents settle against known state; agents can act on one confirmation; bridges and (later) IBC transfers inherit fast, safe settlement. Marketing aside, determinism removes entire classes of wallet, exchange, and solver complexity.

5.3 Liveness and safety posture

Safety (no two conflicting finalized blocks) holds under the standard BFT assumption of less than one-third Byzantine voting power. Liveness is protected operationally: downtime jailing removes stalled validators from the active set, Sentinels pause affected message types if anomalies appear (Section 8.4), and governance can un-pause. Slashing history feeds Genesis Score, so consensus misbehavior follows validators economically beyond the immediate penalty.

---

5.4 Validator lifecycle

Becoming a validator is permissionless but bonded: acquire GEN, self-delegate at least 1000 GEN, and enter the active set (capped at 100 by voting power). From there the protocol watches continuously. Missing blocks triggers downtime slashing (0.01%) and 10 minutes of jailing - enough to sting, calibrated not to destroy honest operators for network hiccups. Double-signing triggers 5% slashing and tombstoning: permanent, public, reputation-destroying removal. Leaving is deliberate: unbonding takes 21 days, during which stake still secures the chain and still earns. Every transition - join, jail, tombstone, unbond - is an on-chain event feeding both the explorer and Genesis Score.

5.5 Finality as an interface

Because finality is deterministic, every consumer of chain state can be simpler. Exchanges credit deposits on one block. The explorer never shows reorganizations. Solvers simulate against state that cannot be revised beneath them. Agents trigger real-world actions - pausing message types, releasing escrows, escalating pages - on single confirmation without confirmation-count heuristics. This simplicity is a security property in itself: each confirmation counter, pending-state branch, and reorg handler in a traditional stack is code that can be wrong, and Genesis deletes the entire category.

5.6 A round in plain language

Each height, the protocol selects a proposer weighted by stake. The proposer broadcasts a block of ordered transactions. Validators check validity and broadcast prevotes; seeing two-thirds prevotes, they broadcast precommits; seeing two-thirds precommits, the block is final and every node commits it. The whole round takes about two seconds on devnet. There is no mining puzzle and no longest-chain rule - finality is voted, explicit, and immediate, which is why a committed block can never be revised.

6. Multi-token economics

One asset cannot simultaneously be a staking asset, a gas asset, a privacy reward, an AI-compute reward, and an RWA fee unit without the roles interfering. Genesis separates concerns across two native coins and three module tokens with a unified sink: module success deflationarily strengthens the gas coin.

6.1 The assets

GEN and GENX are the chain's two coins - protocol-level assets of the chain itself (staking/governance and gas roles baked into consensus and the ante handler). PRIV, AITK, and RWAT are module tokens - protocol-issued bank denoms whose value comes from the module that issues and consumes them. All five bridge to ERC-20 contracts on the EVM layer (cosmos/evm token pairs); the wrapper is a bridge format, not the asset's identity.

GEN's 1-billion cap is enforced in code: the mint function is disabled at genesis. GENX is the volatile-supply workhorse coin — emitted to pay for work and bootstrap staking, burned by protocol usage. The protocol publishes a live net-supply widget, and net emission at or below the burn rate is the declared deflationary status of the system. GENX emissions begin at 200M per year for Work Provisioning and staking bootstrap, decaying 20% per year.

6.2 The fee split (x/feeburn)

Every transaction fee is divided deterministically:

• 50% → burn address. A module account with no spend capability — provably unspendable on-chain. Destruction, not redistribution.
• 30% → staking rewards pool. Pays the validators and delegators who secure the chain.
• 15% → treasury (community pool). Funds development, audits, and ecosystem grants under governance control.
• 5% → block proposer. Direct reward for proposing.

Ratios are governance parameters, adjustable by vote. Every split emits a FeeBurned event, surfaced by the explorer as a live burn counter — burn is both mechanism and Schelling point for the community.

6.3 Cross-module sink: MOD auto-convert

Fees paid in PRIV, AITK, or RWAT accumulate in a module account. Every 100 blocks, an on-chain AMM mechanism (GENX/PRIV, GENX/AITK, GENX/RWAT pairs seeded at launch, executed by a keeper job and later by agents) swaps accumulated module fees into GENX and routes the proceeds to burn, emitting ModuleFeeConverted events. The economic statement: when any module of the protocol succeeds, the gas coin gets scarcer. Privacy usage, AI usage, and RWA fees all become GENX buy-and-burn pressure.

6.4 EVM representation

All five native assets bridge to ERC-20s at canonical token-pair addresses (following the ethermint predeploy pattern) so EVM dApps, wallets, and tooling see ordinary ERC-20s. Fee-routing math carries 100% branch-coverage tests, including fuzzing of the split logic.

---

6.5 Emission schedule and deflationary status (illustrative)

GENX emissions start at 200M per year and decay 20% annually:

Against this declining schedule stands the burn: 50% of every fee plus the 5% work-protocol fee plus periodic MOD conversions. Deflationary status - the protocol's headline economic state - is declared when measured net emission (emissions minus burns over a trailing window) is at or below zero, and the explorer's net-supply widget makes that state legible to everyone in real time. The design intent is explicit: early years bootstrap with emissions while usage is low; as usage grows, burns overtake emissions and the gas token structurally appreciates against activity. Whether and when crossover occurs is an empirical question the chain answers in public.

6.6 Staking rewards

The 30% staking share flows through the distribution module to the active validator set in proportion to voting power. Operators take a declared commission; the remainder accrues to delegators, compounding automatically until claimed. Because the rewards pool is fed by a fixed share of real fee flow (plus scheduled GENX emissions during bootstrap), staking yield is a function of chain usage rather than arbitrary inflation - validators earn more exactly when the protocol is used more. Unbonding delegations stop earning at the moment unbonding begins, and the 21-day unbonding period applies equally to validators and delegators.

6.7 Native tokens on the EVM

Each native denomination maps to an ERC-20 predeploy at a canonical address, so MetaMask, Foundry scripts, and existing dApps interact with the native assets as ordinary ERC-20s - balances, allowances, and events included. The mapping is bidirectional: EVM-side transfers settle against the same bank balances the native modules see, and fee routing applies identically regardless of which runtime submitted the transaction. Predeploy addresses are fixed at genesis and registered publicly; any deviation would fragment tooling trust, so they are treated as immutable protocol constants. Devnet status: four of the five pairs are live (agenx, upriv, uaitk, urwat); the ugen pair registration is the remaining step.

6.8 Why two base tokens

Staking assets and gas assets want opposite properties. A staking asset should be scarce, stable in supply, and attractive to hold - it prices long-term security. A gas asset should track usage: cheap when the chain is idle, appreciating as activity burns it. Forcing one token into both roles creates the familiar pathology: high staking yields paid in inflation that debases the very asset securing the chain, or gas fees so volatile that usage collapses. Genesis separates them. GEN is fixed-supply security collateral with governance rights. GENX is the elastic medium of exchange whose supply breathes with emissions and burns. Stakers earn in the asset users actually spend (plus bootstrap emissions), users pay in an asset whose value the protocol's success supports, and neither role distorts the other.

7. Work Provisioning

Work Provisioning is the signature system of Genesis: a decentralized market where computation itself — proofs, inference, storage, audits — is posted, executed, verified, and settled on-chain.

7.1 The on-chain market (x/work)

A WorkOrder is {id, job_type, spec_hash, bounty_denom, bounty_amount, deadline, capability_class, poster, status}. Job types: ZK_PROOF, AI_INFERENCE, DA_STORE, AUDIT_SPOTCHECK, SPONSORED_COMPUTE.

Lifecycle:

1. Post. A user, the AI layer, or a sponsor posts an order with the bounty escrowed on-chain.
2. Commit. A worker commits with a stake lock (msg.CommitWork) — skin in the game before seeing full details.
3. Execute. The worker runs the job off-chain.
4. Submit. The worker posts msg.SubmitResult{result_hash, execution_proof}.
5. Verify and settle. Verification follows a ladder by job type (below). Valid results release the bounty minus a 5% protocol fee routed to x/feeburn. Invalid results slash 50% of the worker's stake, split between the bounty backer and burn.

7.2 The verification ladder

Verification cost must scale with the trust required — not every job needs a proof:

• ZK proofs are verified on-chain (precompile/contract verifier; SP1 or RISC Zero toolchains for provable Rust workloads). Mathematics, not trust.
• AI inference and other non-deterministic jobs use redundant execution: 3 workers, 2-of-3 hash match, plus Auditor-agent spot checks. Agreement among independent executors substitutes for determinism.
• Data-availability storage uses random sampling challenges — cheap to check, expensive to fake at scale.
• Audit jobs use stake-weighted assignment with mandatory double-verification.

Worker completion history feeds Genesis Score (Section 9): reliable workers compound reputation, which compounds future earnings and terms.

7.3 The Workbench

The Workbench is a native desktop client built in Rust (Windows, macOS, Linux) that turns consumer hardware into protocol income:

• Hardware scan produces a worker profile (GPU/CPU/RAM/disk, capability class); settings cap resource use, active hours, job types, and minimum bounty.
• A background service polls the Work Market over RPC, commits, executes in per-job sandboxed processes, and submits — crash-proof by isolation.
• The dashboard shows jobs completed, earnings by token, Genesis Score progress, and burn contribution ("your work burned 1,204 GENX this week" — every worker sees their deflationary footprint).
• Distribution is professional: auto-updates, macOS notarization, Windows EV code-signing.

7.4 Sponsored compute

Institutions buy bulk compute through an HTTP gateway; orders land on-chain as SPONSORED_COMPUTE with USD billing off-chain and token escrow on-chain. This is Phantom Workz's first revenue stream from Work Provisioning — and every sponsored job still pays the 5% protocol fee into the burn path.

---

7.5 The five job types

• ZK_PROOF: arbitrary provable computation (rollup batches, inference proofs, identity claims). Orders carry a spec hash pointing at the proving circuit; verification is mathematical.
• AI_INFERENCE: non-deterministic model runs (scoring, classification, generation). Redundant 3-worker execution with 2-of-3 hash match, plus Auditor spot-checks between disagreements.
• DA_STORE: data-availability pledges policed by random sampling challenges - cheap to verify, ruinous to fake at scale.
• AUDIT_SPOTCHECK: review tasks (contract audits, result disputes, log reviews) assigned by stake weight with mandatory double verification.
• SPONSORED_COMPUTE: institution-bought bulk jobs - rendering, training, simulation - routed like any order but billed in fiat off-chain.

Capability classes (GPU-heavy, CPU, storage, trusted) in each order let workers filter for jobs their hardware can fill, so posters pay only for suitable execution and workers never race hardware they don't have.

7.6 The sponsored-compute flywheel

Sponsored compute closes the loop between enterprise demand and protocol deflation. Institutions buy bulk computation through a familiar HTTP gateway; orders land on-chain with escrowed bounties; the global worker base fills them; the 5% protocol fee burns. Each cycle does three things at once: revenue for Phantom Workz, income for workers, and GENX destruction. The burn contribution dashboard makes the third visible per worker, turning abstract tokenomics into a personal scoreboard. As more institutions buy in, bounties deepen, more hardware joins, verification redundancy cheapens through scale, and the burn accelerates - a demand-driven flywheel that does not depend on speculation.

8. Agent framework

Agents — persistent software actors — are first-class protocol citizens with identity, stake, permissions, and liability. Not bots with keys; regulated participants.

8.1 The registry

The Agent Registry (a CosmWasm contract) records each agent as {agent_id, operator_address, tier, stake, certified_build_hash, permissions[], status}. The operator address binds legal liability to a real party. The certified build hash binds behavior to audited code: agent transactions must carry a build-hash proof matching the registry, and mismatches are rejected on-chain. Tiers T1–T4 grant escalating permission scopes; from T3 up, irreversible actions require the Two-Agent Rule — a co-signature from a second agent under a different operator.

8.2 Sentinel: the first agent

Sentinel (T1, graduating to T2) is the protocol's immune system: a Go daemon consuming node RPC/WebSocket feeds and Prometheus metrics, watching for block stalls over 10 seconds, validator downtime spikes, oracle deviations over 5%, fee-flow anomalies, and transaction spam patterns. On detection it issues msg.CircuitBreak against the SDK's x/circuit module — pausing only the affected message types, never the chain, with un-pausing reserved to governance. Every action and its justification enters an append-only, hash-chained log whose root is posted on-chain daily; escalation fires to Discord, Telegram, and PagerDuty.

8.3 Auditor

The Auditor agent spot-checks Work Market results and other agents' logs, with random rotation and a rule against auditing the same operator twice in a row — collusion resistance by construction.

---

8.4 Permission tiers

Graduation between tiers requires higher stake, longer clean history, and governance approval. Revocation is fast: a proven build-hash mismatch or a successful fault challenge drops an agent's status immediately, with stake slashed per registry rules. The asymmetry is intentional - trust is earned slowly and lost instantly.

9. Genesis Score

Genesis Score (GS) is a 0–1000 on-chain reputation metric computed at state transition, queryable over gRPC/REST, and exportable as a signed attestation ("GS 741 as of block X", verifiable offline by institutions).

9.1 Inputs and weights

Repayment behavior dominates by design: the score's killer application is undercollateralized lending (a post-mainnet module), where GS replaces locked collateral. Any lending contract — present or future — feeds repayment events through a standard RepaymentEvent hook, so the score improves the more of the ecosystem adopts it.

9.2 Economic role

Score is not a badge; it is an input to terms. Higher scores unlock better borrowing terms, preferred solver routing, and worker opportunities; slashing and defaults drag it down with the 15% negative weight biting hardest on thin histories. The wallet renders score, percentile, and improvement tips — positioning it as the credit-score app of crypto — and the explorer offers public lookup. A GS API product (licensed to institutions) is a planned company revenue stream.

---

9.3 Reading a score (illustrative)

Scores combine the weighted inputs into a single 0-1000 value, with slashing applied as a negative adjustment that bites hardest on thin histories. A two-year validator with clean operations, steady governance votes, and completed work orders sits high: age, volume, work, and governance all contribute, and the absence of slashing leaves the total intact. A new account starts low regardless of balance - without age or repayment history there is little to trust yet, which is exactly correct. A slashed account drops sharply even with strong positives elsewhere, because consensus misbehavior is the strongest available signal of untrustworthiness. The exact combination formula is an implementation parameter specified in ARCHITECTURE.md and tunable by governance; the principle - reward sustained good behavior, punish proven bad behavior disproportionately - is constitutional.

9.4 Attestations and the GS API

A signed attestation packages an address, its score, the block height of computation, and a validator-set signature into JSON any third party can verify offline - no chain access required. Lenders, employers, and partner protocols consume these instead of integrating a node. The GS API productizes this: rate-limited, licensed access to scores, percentiles, and history, with the query volume itself becoming a company revenue stream. Attestations expire by height, forcing freshness; a stale attestation verifies cryptographically but advertises its age, so relying parties choose their own recency policy.

9.5 Gaming resistance (design notes)

Any score gets farmed. Age farming (dormant accounts) is blunted because age is only 10% while volume and quality dominate. Wash trading inflates volume but pays fees - half of which burn, making farming a donation to GENX holders. Work-completion farming requires staked commits and must pass verification; failing burns stake. The residual risk is patient, well-funded sybils - accepted as the cost of an open system, bounded by the negative slashing weight and by governance-tunable parameters. Exact anti-gaming rules (decay rates, minimums, challenge windows) are implementation detail for ARCHITECTURE.md, not constitutional text.

10. Intent and solver layer

Users should declare goals, not construct transactions. An intent is signed JSON — e.g. {want: "swap 1 GENX → max PRIV", constraints: {min_out, deadline, max_fee}} — submitted to a public intent mempool. Registered solvers (T2 agents and human operators) gossip over intents, simulate routes across protocol modules and AMMs, and submit fulfillment transactions. Settlement runs through an escrow contract: intent → escrow → best fulfillment wins → payout. Version 1 protects against MEV with an encrypted mempool via commit-reveal, so intents stay private until settled — no sandwiching the user's own goal.

The wallet's intent composer turns this into one-tap UX: type a goal, see the best solver quote with a full simulation, execute. Success is measured directly: solver routing must beat the naive path on devnet, with MEV simulations showing no sandwich opportunity.

---

10.1 Intent lifecycle in detail

1. Compose. The wallet helps the user express a goal with constraints (minimum output, deadline, maximum fee).
2. Sign and submit. The intent enters the encrypted mempool; its contents stay private under commit-reveal.
3. Simulate. Solvers compete, simulating routes across protocol modules and AMMs against current state.
4. Fulfill. The best fulfillment is submitted; the escrow contract verifies constraints on-chain before releasing anything.
5. Settle. The winner is paid, the user receives at least the quoted minimum, and the reveal phase opens the intent for audit.
6. Challenge. A fulfillment that violates constraints is slashable - solvers stake for the right to compete, and cheating costs the stake.

11. Governance

Genesis uses the SDK's governance module with community-controlled parameters: fee-split ratios, emissions posture, module parameters, treasury spending, and circuit-breaker un-pausing all flow through votes. Design choices worth noting:

• Circuit breaking is pause-only for agents. Sentinel can stop bleeding; only governance can restart — emergency power without emergency dictatorship.
• Treasury discipline. The 15% fee share accrues to the community pool, spendable only by passed proposals, with the insurance fund (5% of launch treasury) seeded at mainnet.
• Progressive decentralization. The foundation (OpenCode, GEN) stewards launch; control migrates to token-holder governance as the validator set and agent ecosystem mature.

---

11.1 What governance decides

• Economic parameters: fee-split ratios, emissions posture, AMM seeding.
• Protocol evolution: module upgrades, new message types, circuit-breaker un-pausing.
• Treasury: community-pool spending, grants, insurance-fund activation.
• Membership: validator-set-adjacent policies, agent tier graduations, registry disputes.
• Emergency powers are deliberately asymmetric: pausing is fast and delegated (Sentinel), un-pausing is slow and collective (vote). The system can stop quickly but can only restart deliberately.

11.2 Progressive decentralization

At devnet the core team operates every validator and parameter. Testnet distributes operations to 25-50 external validators while the team retains upgrade keys under timelock. At mainnet the OpenCode foundation stewards treasury and emergency response alongside elected validators, with a published schedule for transferring upgrade authority, treasury control, and parameter defaults to token-holder governance. Decentralization is measured in the explorer like any other metric - Nakamoto coefficient, geographic distribution, client diversity - because a protocol selling trust must show its own.

12. Security model

Defense in depth, with each layer assuming the others can fail:

1. Consensus safety from BFT two-thirds quorums; liveness from jailing plus Sentinel response.
2. Economic security from staked validators (1000 GEN minimum self-delegation), committed workers (stake locks), slashing (downtime and double-sign), and score-mediated terms.
3. Execution safety from 100%-coverage fee math, audited contracts, and the verification ladder for off-chain work.
4. Operational safety from pause-only circuit breakers, hash-chained agent logs, and professional key handling in wallet and Workbench (audited updater signing, sealed storage).
5. External assurance from competitively-run audits (Code4rena/Sherlock class, $60k–$150k budget) covering chain modules, contracts, and clients — with all critical and high findings closed and re-audited before mainnet.
6. Financial backstop from the insurance fund and, post-launch, the governance-activated insurance program.

---

12.1 Threat model (summary)

13. Roadmap to mainnet

Post-launch runs in quarters: GS-based undercollateralized lending and intent-layer GA (Q1); the PRIV privacy layer with compliance proofs (Q2); the AITK AI module, RWA wrappers, and data APIs (Q3); insurance activation, Celestia evaluation, reputation markets, mobile GA (Q4). Twenty percent of all company revenue funds quarterly GEN buyback-and-burn by governance-approved treasury program.

Realistic timeline to mainnet: 14–16 months.

---

13.1 Phase gates

Each phase exits only through its gate: docs complete and committed; live site with 90+ Lighthouse and working email capture; 4-node devnet stable 72 hours with Foundry-driven EVM transactions and green CI; fuzz-tested fee math, a provably unspendable burn address, the MOD-burn loop firing every 100 blocks, verified wrappers; sub-3-second explorer freshness with a live burn counter; a published extension with working delegation, voting, and score panel; sub-15-minute fresh-node installs with live Grafana; paid work orders filled end-to-end with verified slashing on bad submissions; sub-15-second Sentinel pauses with rejected forged agent transactions; scores that move with behavior plus offline-verifiable attestations; solver-executed intents beating naive routing with no sandwich; 30+ days, 1,000+ external work orders, clean audits; 14 incident-free days. A missed gate stops the line - schedule pressure never overrides it.

13.2 Risks and open questions

Currency risk in the burn thesis: if GENX price falls faster than fee volume grows, burns may never overtake emissions - the crossover is a market outcome, not a guarantee. Execution risk in the verification ladder: redundant execution assumes worker independence, which stake-distribution monitoring must enforce. Concentration risk in sponsored compute: a single large buyer could dominate bounties; per-poster rate limits are under consideration. Technical risk in the EVM integration: the concrete module fork and its SDK v0.50 compatibility must be pinned before devnet (ARCHITECTURE.md). Regulatory risk: the entire token timeline assumes counsel's sign-off at Section 12; an adverse opinion stops the line. Naming these now is deliberate - each has an owner, a section, and a gate.

14. Legal and compliance posture

• No tokens are created or sold before testnet completion, external audits, and legal review. A no-token-offering memo sits in company records.
• The Token Generation Event is planned with securities counsel on a non-offering basis (US + EU assumed), limited to testnet and work-provider participants unless counsel signs off otherwise.
• The GEN foundation (OpenCode) is formed for mainnet with a Panama foundation + Cayman SPV structure.
• Privacy features ship with compliance proofs; agent operators are liability-bound on-chain; trademarks and domains are secured early.

---

15. Conclusion

Genesis Protocol is built on a single conviction: the next leap in blockchains is not throughput but trustworthiness made legible to the machine. Score it, stake it, insure it, compound it — and capital, computation, and agency can coordinate at a scale that collateral and handshakes never allowed. The mechanism design (burns with sinks, work with verification, agents with liability, reputation with teeth) exists to make honest participation the highest-yielding strategy on the network.

Build in order. Test everything. Ship the vision.

---

Appendix A — Token specifications

Fee split on every transaction: 50% burn · 30% staking rewards · 15% treasury · 5% proposer. MOD fees auto-convert to GENX and burn every 100 blocks.

Appendix B — Chain parameters

B.1 Performance envelope (measured + targets)

Measured on the live devnet (single node, containerized, 2026-09-29) and stated targets — honest about real vs theoretical:

The protocol does not publish speculative TPS. Throughput claims ship only after the multi-node load harness runs on testnet (a plan gate before mainnet). The theoretical ceiling above exists so readers can sanity-check that the design point leaves headroom — it is not a promise.

B.2 Validator requirements (testnet baseline)

Appendix C — Glossary

• Work Provisioning — the on-chain compute market (x/work) plus the Workbench client.
• Work Order — a posted unit of paid computation with escrowed bounty.
• Verification ladder — job-type-dependent result checking (proofs, redundancy, sampling, double-verification).
• Genesis Score (GS) — the 0–1000 on-chain reputation metric (x/gscore).
• Sentinel — the T1→T2 monitoring agent with pause-only circuit powers.
• Two-Agent Rule — T3+ irreversible actions need a second agent's co-signature from a different operator.
• FeeBurned / ModuleFeeConverted — the canonical burn-accounting events.
• Intent — a signed declaration of a desired outcome, fulfilled by solvers through escrow.
• Deflationary status — the declared state when GENX net emission is at or below the burn rate.
• Predeploy — a contract available at a fixed address from genesis (here: ERC-20 wrappers of native denominations); treated as immutable.
• Commit-reveal — the v1 intent-privacy scheme: intents are committed encrypted and revealed only at settlement, defeating sandwiching.
• Tombstoning — permanent removal of a double-signing validator.
• Unbonding — the 21-day exit queue during which stake still secures the chain and still earns, but cannot be moved.
• Sponsored compute — institution-bought bulk computation posted as on-chain work orders with off-chain USD billing.
• Circuit breaker — the SDK x/circuit facility Sentinel uses to pause targeted message types (pause-only; governance un-pauses).