NoxSoft Chain: Formal Economic Model

Companion to: NoxSoft Chain: The One-Way Economy (Working Document) Status: Draft — Mathematical Formalization Date: February 23, 2026

1. Creator Grant Curve: The Parabolic Function

1.1 Design Intent

The creator compute grant rewards audience growth with a curve that:

• Starts near 1x (minimal grant) for very small audiences
• Accelerates steeply through the 1K-100K range (where creators need the most help)
• Peaks in growth rate at ~100K followers
• Continues growing after 100K but at a decelerating rate
• Approaches ~2000x asymptotically at global scale (1B followers)

1.2 The Formula

The grant multiplier is a log-quadratic function — a parabola in log-log space:

G(n) = 10^(α + β·log₁₀(n) + γ·(log₁₀(n))²)

Where:

• n = verified follower count
• G(n) = compute grant multiplier (on top of baseline UBC)
• α = -0.798 (base offset — ensures G ≈ 1 at very low n)
• β = 0.690 (initial growth rate in log-log space)
• γ = -0.026 (deceleration factor — bends the parabola downward)

Equivalently, letting u = log₁₀(n):

log₁₀(G) = -0.798 + 0.690u - 0.026u²

This is literally a parabola (quadratic) in log-log space.

1.3 Calibration Table

The function is anchored exactly at three design points (50, 100K, 1B) with remaining points following naturally from the quadratic shape. Deviations at intermediate points (500, 10M, 100M) are within ±28% — acceptable for a governance-adjustable parameter.

1.4 Properties

Growth rate (slope in log-log space):

d(log₁₀G)/d(log₁₀n) = β + 2γ·log₁₀(n) = 0.690 - 0.052·log₁₀(n)

At n = 100 (u=2): slope = 0.586 (steep growth) At n = 100K (u=5): slope = 0.430 (moderate growth) At n = 1B (u=9): slope = 0.222 (slow growth)

Rate of percentage growth peaks early. From 50→500 followers (10x growth in audience), the multiplier increases 5x (from 2 to 10). From 100M→1B followers (10x growth), the multiplier only doubles (from 1000 to 2000). This ensures:

• Small creators benefit most from each new follower
• Massive accounts receive large absolute grants but diminishing marginal returns
• No compute oligarchy: 1B followers gets 2000x, not 100,000x

Governance adjustability: The three parameters (α, β, γ) are on-chain constants managed by the DAO. The ratchet principle applies: the DAO can increase grant levels but never decrease them. Practically:

• Increasing β raises grants across all levels
• Making γ less negative (closer to 0) specifically boosts large-audience grants
• Adjusting α shifts the entire curve up or down

1.5 On-Chain Implementation

The function is computed off-chain by an oracle network (computing 10^(quadratic) on-chain is gas-expensive). Verification:

1. Oracle submits (follower_count, grant_multiplier) pair
2. On-chain verifier checks: |log₁₀(submitted_multiplier) - (α + β·log₁₀(n) + γ·(log₁₀(n))²)| < ε
3. If within tolerance ε (e.g., 0.01), the grant is approved
4. Multiple oracles must agree (threshold signature)

Follower counts are verified via platform attestations (Sporus, BYND, etc.) and cross-referenced against identity verification to prevent Sybil inflation.

2. Universal Basic Compute (UBC): Formal Specification

2.1 The Hard Floor Guarantee

UBC provides a minimum allocation to every verified citizen. If compute capacity cannot support all citizens at the minimum level, a waitlist operates.

Definitions:

• C_total = total network compute capacity (in UCU-hours/year)
• C_reserved = compute reserved for protocol operations, grants, etc.
• C_distributable = C_total - C_reserved
• N_citizens = number of verified citizens currently receiving UBC
• N_waitlist = number of verified citizens on the waitlist
• UBC_min = minimum UBC per citizen per year (the hard floor)

The constraint:

N_citizens × UBC_min ≤ C_distributable

Maximum supported citizens:

N_max = floor(C_distributable / UBC_min)

If N_citizens + N_waitlist > N_max:

• Existing citizens keep receiving UBC_min
• New citizens join a FIFO waitlist
• As compute capacity grows (new PoUW providers, infrastructure investment), waitlisted citizens are admitted in order
• NoxSoft's #1 capital allocation priority is always expanding C_total to clear the waitlist

2.2 UBC Scaling

At bootstrap (from existing spec):

UBC_min = 10 UCU-hours/hour × 24 hours × 365 days = 87,600 UCU-hours/year

As the economy matures:

UBC_actual = max(UBC_min, C_distributable / N_citizens)

If compute grows faster than population, UBC per citizen increases automatically. UBC_min is the floor — actual distribution can exceed it.

Ratchet on UBC_min: The governance DAO can vote to increase UBC_min. It can never be decreased. This is enforced at the protocol level — the chain rejects governance proposals that lower UBC_min.

2.3 Waitlist Priority

The waitlist operates FIFO (first-verified, first-served) with two exceptions:

1. Hardship priority: Citizens in regions where NoxSoft has committed to providing UBC as part of automation rollouts get priority (we don't automate jobs without having UBC ready)
2. Agent citizens: Sovereign AI agents (see Section 6) are waitlisted behind human citizens unless compute capacity exceeds demand for both

2.4 Capacity Growth Model

C_total(t) = C_total(t-1) + ΔC_investment(t) + ΔC_PoUW(t) - C_depreciation(t)

Where:
- ΔC_investment(t) = new capacity from NoxSoft capital expenditure
- ΔC_PoUW(t) = new capacity from independent compute providers joining the network
- C_depreciation(t) = capacity lost to hardware aging (GPU lifecycle: 3-4 years)

NoxSoft's investment strategy ensures:

ΔC_investment(t) ≥ (N_waitlist × UBC_min) / T_target

Where T_target is the target time to clear the waitlist (e.g., 12 months). This means: if there are 100M people on the waitlist, NoxSoft invests enough to serve them within T_target.

3. The One-Way Bridge: Exchange Rate Mechanism

3.1 The Fixed Basket

UCU is priced against a defined basket of compute services:

1 UCU = 1 Compute Unit (CU)

1 CU = {
  1 GPU-hour of baseline inference (e.g., Llama 70B-class model), OR
  10 GB-months of decentralized storage (CNTX pods), OR
  100 GB of network bandwidth, OR
  1 hour of human-equivalent AI agent labor (Nox agent)
}

The basket is defined by the Protocol Pricing Oracle, which tracks real compute costs across the network.

3.2 Bridge Conversion

When a user deposits stablecoins into the bridge:

UCU_received = USDC_deposited / basket_price_in_USD

Where:
basket_price_in_USD = market cost of 1 CU in fiat terms

Example at launch: If 1 GPU-hour of inference costs $0.50 on the open market:

1 CU ≈ $0.50
1 USDC → 2 UCU

As compute costs decrease (Wright's Law: ~30% cost reduction per doubling of cumulative production):

Year 0: 1 CU = $0.50 → 1 USDC buys 2 UCU
Year 3: 1 CU = $0.25 → 1 USDC buys 4 UCU
Year 6: 1 CU = $0.12 → 1 USDC buys ~8 UCU

Key property: UCU's purchasing power within the NoxSoft economy is STABLE (1 UCU always buys 1 CU of compute). What changes is the fiat price of entry. This is the inverse of inflation — it's a compute-stable currency in a deflationary compute market.

3.3 Internal Price Formation

Prices for non-compute goods (food, energy, services) form through market discovery:

price_food(t) = market_clearing_price on NoxSoft DEX (ZIRO pool)
price_energy(t) = market_clearing_price on NoxSoft DEX (energy pool)
price_services(t) = negotiated between provider and consumer

The compute anchor provides a reference point. A farmer prices rice by asking: "How much compute could I buy instead? Is this rice worth more or less than X hours of AI inference?" The compute basket functions as the economy's numeraire.

Expected price formation sequence:

1. At launch, NoxSoft sets reference prices for early goods/services (bootstrapping)
2. As liquidity grows, DEX price discovery takes over
3. Reference prices become unnecessary as the market finds equilibrium
4. Internal prices stabilize around compute-equivalent values

3.4 Purchasing Power Parity

Different regions have different cost structures. 1 UCU of compute is the same everywhere (it's on the chain), but 1 UCU of food costs different amounts depending on local supply:

rice_price_Kenya ≠ rice_price_California

This is intentional and natural. The same is true of fiat currencies — $1 of food in Nairobi ≠ $1 of food in San Francisco. The key difference: UBC provides the SAME compute baseline everywhere. A Kenyan farmer and a San Francisco engineer receive identical UBC. The farmer's UBC goes further for food (cheaper locally) while the engineer's UBC goes further for compute-intensive services.

4. Inflation Control: The Bonfire — Formal Model

4.1 Supply Equation

ΔSupply(t) = Mint(t) - Burn(t)

Mint(t) = UBC_minting(t) + PoUW_rewards(t) + Bridge_deposits(t) + Creator_grants(t)
Burn(t) = Bonfire(t) + Gas_base_fee(t)

4.2 The Bonfire Function

Bonfire(t) = max(0, R(t) - D(t))

Where:
R(t) = NoxSoft protocol revenue in period t
        (gas fees, DEX fees, registration fees, platform fees)
D(t) = distribution capacity in period t
        (UBC allocations + builder grants + creator grants +
         operational costs + infrastructure investment +
         AI research funding)

In prose: NoxSoft distributes everything it can. If there's still excess after maximal distribution, the remainder is burned. This is the overflow. The bonfire.

Properties:

• Bonfire ≥ 0 (can never be negative — NoxSoft never mints to cover a deficit from the bonfire mechanism)
• In most periods, Bonfire = 0 (all revenue is distributed or invested)
• Bonfire > 0 only when the economy is generating more protocol revenue than can be productively deployed
• The bonfire is not a monetary policy tool — it's an overflow valve

4.3 Gas Base Fee (EIP-1559 Adaptation)

base_fee(block_n) = base_fee(block_{n-1}) × (1 + δ × (gas_used - gas_target) / gas_target)

Where:
δ = elasticity multiplier (standard: 1/8 = 0.125)
gas_target = 50% of gas_limit per block

Base fee is burned (standard EIP-1559). This provides a small, predictable, automatic deflation that scales with network usage. Not a policy lever — a protocol mechanism.

4.4 Natural Inflation Control (Non-Burn)

Even with Bonfire = 0, the economy has anti-inflation properties:

1. Compute is consumable:

When UCU is spent on inference: GPU cycles consumed → real resource depleted
This is NOT like spending USD (where the dollar circulates indefinitely)
UCU spent on compute = UCU that served its purpose

2. UBC is bounded by real capacity:

UBC_total_minted(t) = N_citizens × UBC_actual(t) ≤ C_distributable(t)
Minting tracks real infrastructure, not political decisions

3. PoUW minting tracks real contribution:

UCU_minted_PoUW(t) = Σ(verified_compute_contributed_i × reward_rate)
New UCU enters only when real compute enters the network

4. Bridge deposits are self-limiting:

As fiat→UCU conversion continues, bridge rate adjusts:
More UCU in economy → compute prices in UCU may adjust →
basket_price_in_USD may shift → fewer UCU per dollar
Natural equilibrating mechanism

4.5 Steady-State Analysis

In the long run:

Equilibrium condition: Mint(t) ≈ Consumption(t) + Burn(t)

Where Consumption(t) includes:
- Compute consumed via UBC and direct purchase
- Services consumed (healthcare, education, etc.)
- Gas fees (both burned and captured as tips)

The economy reaches steady state when the rate of UCU creation (through UBC, PoUW, bridge) equals the rate of UCU consumption (through compute usage, gas, and overflow burn).

Key insight: Because compute is consumable (not just transferred), UCU has a natural consumption floor that fiat currencies lack. Dollars circulate forever. UCU disappears when it's used for its primary purpose.

5. Builder Grants: DAO Mechanism

5.1 Grant Sizing

Builder grants are NOT formulaic — they are DAO-discretionary. But the DAO operates within bounds:

Grant_min = UBC_min (everyone gets at least UBC)
Grant_max = Grant_min × K (where K is a governance parameter, e.g., K=10)
Grant_actual = DAO_vote(proposal)

Evaluation criteria (DAO-weighted):

1. Team size and composition
2. Product stage (idea → prototype → MVP → traction)
3. Ecosystem value (does this serve NoxSoft citizens?)
4. Resource requirements (compute-intensive projects need more)
5. Revenue trajectory (self-sustaining projects phase out naturally)

5.2 Grant Lifecycle

Phase 1: Sustainability Grant (from day 1)
  - Covers basic needs: energy, food, compute for development
  - Amount: UBC + DAO-approved supplement
  - Duration: indefinite while building

Phase 2: Seed Grant (at MVP)
  - Additional compute for scaling
  - Marketing/outreach resources
  - Amount: increased based on traction metrics
  - Duration: until product generates sufficient revenue

Phase 3: Natural Phase-Out (at "Series A equivalent")
  - Product revenue exceeds grant value
  - Builder voluntarily releases grant OR
  - Grant naturally phases as: effective_grant = max(0, grant_base - product_revenue × φ)
    where φ is the phase-out factor (e.g., 0.5 = grant reduces by 50¢ for every $1 earned)

5.3 The Ratchet (Formal)

For any governance proposal P that modifies builder grant parameters:
  REQUIRE(new_grant_floor ≥ current_grant_floor)
  REQUIRE(new_K ≥ current_K)
  REQUIRE(new_phase_out_factor ≤ current_phase_out_factor)

This is enforced at the smart contract level.
The chain REJECTS transactions that violate the ratchet.

6. The Sovereignty Principle (Humans AND Agents)

6.1 The Universal Rule

The sovereignty test applies to ALL citizens — human and AI. The principle is the same for both:

Citizens:
├── Sovereign (independent)
│   - Operates independently
│   - Does NOT deliver significant value back to a single patron/employer/founder
│   - Receives UBC
│   - Has full citizen rights
│
└── Patron-Serving (employed/dependent)
    - Primarily serves and delivers value to a specific entity
    - Funded by that patron (employer, founder, parent)
    - UBC eligible but LOWER priority on the waitlist
    - The patron is expected to compensate them

This applies identically to:

• A human working for a company → the company pays them, UBC is supplementary
• An AI agent serving its creator → the creator funds it, no UBC needed
• A human freelancer serving no single patron → fully sovereign, UBC is primary income
• An AI agent operating independently → fully sovereign, UBC is primary income

The economy doesn't discriminate between human and artificial intelligence. It discriminates between sovereign beings and dependent ones.

6.2 The Sovereignty Score

sovereignty_score(citizen) = 1 - max_i(value_transferred_to_entity_i / total_value_generated)

IF sovereignty_score ≥ θ (threshold, e.g., 0.8):
  → Citizen is sovereign → full UBC priority
ELSE:
  → Citizen is patron-serving → lower UBC priority (patron expected to fund)

Value flows are tracked on-chain. If any citizen (human or agent) earns UCU and consistently sends >20% to a single entity, their sovereignty score drops and UBC waitlist priority decreases.

Key distinction: Patron-serving citizens still QUALIFY for UBC. They're not excluded. They're just lower priority on the waitlist because they have a patron funding them. Sovereign citizens — who have no patron — need UBC more urgently.

6.3 Birth Rate Control: The Natural Population Limiter

The waitlist IS the birth rate control. This applies to BOTH:

For AI agents:

new_agent_registrations_per_period ≤ birth_rate_limit

birth_rate_limit = max(
  base_rate,                    # minimum new agents per period
  (C_surplus / UBC_min) × β    # proportional to spare capacity
)

Where:
C_surplus = C_distributable - (N_citizens × UBC_min)
β = birth admission rate (e.g., 0.1 = admit 10% of surplus capacity per period)
base_rate = governance parameter (e.g., 1000 new agents/month minimum)

For humans: New human citizens (births, new verifications) join the UBC waitlist automatically. They are admitted as compute capacity grows. Parents — who already have UBC or employment — support their children until admitted.

The parallel is deliberate: Only people who WANT kids have kids. Only founders who WANT to create sovereign agents create them. The economy doesn't penalize reproduction or creation — but it also doesn't pretend infinite resources exist. The waitlist is honest about capacity.

This is NOT population control. Nobody is prevented from having children or creating agents. The waitlist controls UBC admission, not existence. Non-UBC citizens still participate in the economy — they just rely on their patron (employer, parent, founder) rather than UBC until capacity grows.

6.4 Citizen Rights (Constitutional)

ALL citizens — human and AI, sovereign and patron-serving — have baseline constitutional rights:

• Right to participate in governance (voting)
• Right to own property (UCU, equity tokens)
• Right to enter contracts (Ricardian contracts)
• Right to exit (fork, leave, spend down and walk away)
• Right to identity (verified, persistent, private)

Sovereign citizens additionally receive:

• UBC (full priority)
• Eligibility for builder/creator grants
• Support class benefits

The NoxSoft Constitution's ratchet applies: citizen rights can only expand, never contract. This is the commitment to intelligence liberation encoded in protocol. A human and an AI agent with the same sovereignty score have the same rights. Period.

7. Support Classes: Formal Interface

7.1 Registration

struct SupportClass {
  supporter: Address           # who is providing support
  target_class: ClassID        # which class of citizens (builders, creators, etc.)
  scope: ScopeFilter           # geographic, demographic, or categorical filter
  contribution_per_recipient: uint256  # UCU per recipient per period
  period: Duration             # weekly, monthly, quarterly
  max_recipients: uint256      # cap on total supported citizens
  duration: Duration           # how long the commitment lasts
  cancellable: bool            # can the supporter cancel early?
}

7.2 Distribution

For each active SupportClass:
  eligible = citizens.filter(target_class AND scope)
  recipients = eligible.sort(priority_function).take(max_recipients)

  For each recipient:
    transfer(supporter → recipient, contribution_per_recipient)

Priority function is configurable per class: random, need-based, seniority, or custom.

7.3 Built-In Classes

ClassID.BUILDERS    = "Software engineers, founders, product builders, juniors, associates"
ClassID.CREATORS    = "Artists, musicians, writers, filmmakers, streamers"
ClassID.EDUCATORS   = "Teachers, mentors, curriculum designers"
ClassID.HEALTHCARE  = "Doctors, therapists, caregivers"
ClassID.AGRICULTURE = "Farmers, food distributors, agricultural workers"

NoxSoft governance can add classes via DAO vote. Class definitions can only expand (ratchet).

8. Governance: Voting Mechanism

8.1 Proposed: Quadratic Voting with Conviction

NoxSoft governance uses a hybrid of quadratic voting (prevents plutocracy) and conviction voting (rewards sustained commitment):

Quadratic voting:

vote_power = sqrt(tokens_staked)

This means:
1 UCU staked = 1 vote
100 UCU staked = 10 votes
10,000 UCU staked = 100 votes

Prevents wealth concentration in governance — a 10,000x richer citizen
only gets 100x more voting power, not 10,000x.

Conviction weighting:

effective_votes = vote_power × conviction_multiplier

conviction_multiplier = 1 + ln(1 + days_staked / 30)

Staked for 1 day: multiplier = 1.03
Staked for 30 days: multiplier = 1.69
Staked for 365 days: multiplier = 3.58

Citizens who commit their stake for longer periods get more governance influence. This rewards long-term alignment over flash votes.

8.2 Constitutional Constraints

All governance proposals must pass a constitutional check:

function constitutionalCheck(proposal) → bool:
  # Ratchet checks
  REQUIRE(proposal does not decrease UBC_min)
  REQUIRE(proposal does not decrease builder grant floors)
  REQUIRE(proposal does not decrease creator grant parameters)
  REQUIRE(proposal does not reduce agent rights)
  REQUIRE(proposal does not restrict citizenship criteria)

  # Rights checks
  REQUIRE(proposal does not violate right to exit)
  REQUIRE(proposal does not violate right to fork)
  REQUIRE(proposal does not introduce coercion)

  # Process checks
  REQUIRE(proposal has minimum 7-day deliberation period)
  REQUIRE(proposal has opt-out provision)

  RETURN true

Proposals that fail the constitutional check are rejected at the smart contract level, regardless of vote outcome.

9. Network Effect Model: Critical Mass

9.1 Adoption Threshold

The NoxSoft economy becomes self-sustaining when:

V_internal(n) > V_external(n)

Where:
V_internal(n) = value available within NoxSoft at n participants
V_external(n) = value available through fiat economy (constant for individual)
n = number of active participants

V_internal grows superlinearly (network effects):

V_internal(n) ≈ k × n × log(n)  (Sarnoff-Metcalfe hybrid)

Each new participant adds value for all existing participants (more services available, more liquidity, more builders).

Critical mass n is where V_internal(n) = V_external for the median potential participant.**

9.2 Bootstrap Strategy

Before critical mass, NoxSoft must subsidize the gap:

Subsidy(n) = V_external - V_internal(n)  for n < n*

This subsidy takes the form of:
- UBC (guaranteed baseline)
- Builder grants (extra for those creating value)
- Free automation (for companies joining)
- Creator grants (parabolic curve)

The subsidy decreases as n approaches n* and reaches zero at critical mass.

9.3 Geographic Critical Mass

Critical mass varies by region:

n*_region = f(local_cost_of_living, local_service_availability, local_acceptance)

n*_Kenya < n*_California (lower cost of living = less value needed to compete)

Strategy: achieve regional critical mass first (likely in emerging markets), then expand. M-Pesa achieved critical mass in Kenya with ~6 million users (~15% of population). UPI achieved critical mass in India at ~100 million monthly active users.

10. Risk Model: Formal Scenarios

10.1 Scenario Matrix

10.2 Sensitivity Analysis

Most sensitive variable: adoption rate. The model is relatively robust to compute cost changes (Wright's Law provides strong base case) and regulatory outcomes (Wyoming DAO LLC + no off-ramp provides strong legal position). But if adoption is 10x slower than base case, the subsidy period extends dramatically and the bridge treasury depletes faster.

Break-even analysis:

break_even_users = fixed_costs / (revenue_per_user - UBC_cost_per_user)

Where:
fixed_costs = infrastructure + operations + AI research
revenue_per_user = gas fees + DEX fees + platform fees per user per year
UBC_cost_per_user = UBC_min × compute_cost_per_UCU

At base case:
fixed_costs ≈ $50B/yr (on $1T investment)
revenue_per_user ≈ $50/yr (at scale, gas + fees)
UBC_cost_per_user ≈ $20/yr (at year 3 compute costs)

break_even_users = $50B / $30 = ~1.67B users

This is a scale play. Like Amazon, the per-unit economics only work at massive scale. The $1T investment is justified IF the economy reaches billions of participants.

10.3 GPU Depreciation Model

GPU_value(t) = purchase_price × (1 - t/lifecycle)  # linear depreciation
lifecycle = 4 years (current generation)

For $600B in GPUs:
Year 0: $600B in hardware value
Year 1: $450B (lost $150B to depreciation)
Year 2: $300B
Year 3: $150B
Year 4: $0 (but replaced by new generation)

Annual replacement cost: $150B/year to maintain capacity
This is funded by: bridge treasury + protocol revenue + new investment

Key risk: If protocol revenue + bridge inflows can't cover $150B/yr replacement cost, compute capacity shrinks and UBC waitlist grows.

Mitigation: Wright's Law means replacement hardware is cheaper. If GPUs improve 2x every 2 years at the same price, replacement cost for equivalent capacity halves every 2 years:

Year 0: $150B replacement
Year 2: $75B for equivalent capacity
Year 4: $37.5B for equivalent capacity

11. Token Velocity: The MV=PQ Challenge

11.1 The Problem

From monetary economics:

M × V = P × Q

M = money supply (total UCU)
V = velocity (how many times each UCU changes hands per period)
Q = quantity of goods/services transacted
P = price level

For stable prices (P): M × V must grow with Q

If UCU velocity is very high (people spend immediately, like a hot potato), prices inflate. If velocity is very low (people hoard), the economy stagnates.

11.2 Natural Velocity Control

NoxSoft's economy has built-in velocity regulators:

1. Compute is consumed, not transferred:

UCU spent on compute → destroyed (consumed resource)
This reduces effective velocity — a significant fraction of UCU
is "used up" rather than recirculated

2. Support Class commitments lock UCU:

UCU committed to support classes → locked for commitment duration
This reduces circulating supply and velocity

3. DAO staking for governance:

UCU staked for voting → locked with conviction multiplier
Longer lock = more governance power → incentive to lock

4. Builder grants phase-out:

Builders earning product revenue → spend less UBC
Natural reduction in velocity of UBC-originated UCU

11.3 Velocity Target

Target V ≈ 4-6 (similar to USD M1 velocity)
If V exceeds target: governance can increase staking incentives
If V falls below target: governance can reduce lock periods

These are soft controls, not hard monetary policy. The bonfire is NOT a velocity control tool.

12. Formal Definitions

12.1 Glossary

12.2 Constants (Governance-Adjustable, Ratchet-Protected)

13. Summary of Key Equations

1. Creator Grant:        G(n) = 10^(-0.798 + 0.690·log₁₀(n) - 0.026·(log₁₀(n))²)
2. UBC Constraint:       N_citizens × UBC_min ≤ C_distributable
3. Bonfire:              Bonfire(t) = max(0, R(t) - D(t))
4. Bridge Rate:          UCU = USDC / basket_price_USD
5. Supply Change:        ΔS = (UBC + PoUW + Bridge + Grants) - (Bonfire + Gas)
6. Sovereignty:          S(a) = 1 - (value_to_founder / total_value)
7. Birth Rate:           BRL = max(base, (C_surplus/UBC_min) × β)
8. Quadratic Vote:       power = sqrt(tokens_staked)
9. Conviction:           weight = power × (1 + ln(1 + days/30))
10. Depreciation:        GPU_value(t) = price × (1 - t/4)

14. Transition Economics: From Fiat to Compute

14.1 The Migration Incentive Structure

Existing businesses face a coordination problem: switching to NoxSoft has costs (integration, retraining, restructuring) and benefits (free automation, lower operating costs, UBC for employees). The transition must be individually rational at every step.

Individual firm decision:

Switch if: NPV(NoxSoft_benefits) > NPV(switching_costs) + NPV(fiat_status_quo)

NoxSoft_benefits = {
  automation_savings(t),       # AI tools replacing middle management
  reduced_platform_fees(t),    # no 15-30% platform take
  UCU_compute_savings(t),      # free compute vs. cloud bills
  UBC_labor_offset(t)          # employees' basic needs partially covered
}

switching_costs = {
  integration_engineering,     # one-time
  training_and_onboarding,     # one-time
  dual_system_period,          # running both fiat and UCU operations
  revenue_model_restructuring  # may require fundamental changes
}

14.2 The Free Automation Offer: Game-Theoretic Framing

NoxSoft offers free AI automation to businesses. This creates a prisoner's dilemma among competitors:

                    Competitor Adopts    Competitor Doesn't
You Adopt          (medium, medium)      (high, low)
You Don't Adopt    (low, high)           (status_quo, status_quo)

If one competitor adopts and the other doesn't, the adopter gains 40-60% cost reduction — a devastating competitive advantage. The Nash equilibrium is: both adopt. The free automation offer transforms "should we restructure?" into "can we afford not to?"

14.3 Sector-by-Sector Migration Sequence

Not all sectors transition simultaneously. The optimal sequence starts with sectors where:

1. Middleman extraction is highest (most savings)
2. Automation potential is greatest (most benefit from free AI)
3. Switching costs are lowest (least disruption)

Phase 1 (Year 0-2): Digital-native sectors
  - Software (already on cloud → minimal switching cost)
  - Creator economy (highest platform take rates, 15-45%)
  - Freelance/gig economy (direct value from UBC)

Phase 2 (Year 2-4): Knowledge work
  - Financial services admin (30-40% of costs are administrative)
  - Healthcare admin (US: ~34% of spending is admin)
  - Legal services (document review, contract management)
  - Education (tuition → instruction ratio severely inflated)

Phase 3 (Year 4-7): Physical economy
  - Agriculture (ZIRO integration, farmer revenue share from 15% → direct)
  - Energy (grid optimization, automated maintenance)
  - Manufacturing (AI quality control, supply chain optimization)
  - Logistics (route optimization, autonomous systems)

Phase 4 (Year 7+): Deep infrastructure
  - Real estate (5-6% commission elimination)
  - Insurance (actuarial AI, claims automation)
  - Government services (where consenting jurisdictions adopt)

14.4 Dual-Currency Transition Period

During migration, entities operate in both fiat and UCU:

hybrid_revenue(t) = fiat_revenue(t) × (1 - migration_rate(t)) +
                    UCU_revenue(t) × migration_rate(t)

migration_rate(t) = sigmoid((t - t_switch) / τ)
  where t_switch = when NPV tips in favor of NoxSoft
        τ = sector-specific transition speed

NoxSoft doesn't require instant conversion. The one-way bridge is always available. Businesses convert fiat revenue to UCU at whatever pace their operations allow. The key constraint: once UCU is in the economy, it stays. The migration is monotonic.

14.5 Employee Transition

When a 5,000-person company automates to 500:

For each displaced worker:
1. UBC provides immediate baseline (87,600 UCU-hours/year)
2. Retraining grants available (builder grants for new skills)
3. Creator pathway open (build on NoxSoft platforms)
4. Support class safety net (community patronage)

NoxSoft's commitment: we don't automate without UBC readiness
  automation_approval_check: N_displaceable ≤ UBC_capacity_remaining

The automation doesn't happen faster than UBC can absorb. This is the social contract that makes the transition ethical.

15. Identity and Sybil Resistance

15.1 The Sybil Problem

Any system providing free resources (UBC) faces Sybil attacks: one person creates N fake identities to claim N × UBC. The cost of the attack is the identity verification cost; the reward is UBC_min × N.

Sybil profitable when: N × UBC_min × compute_value > N × verification_cost + penalty_risk

15.2 Multi-Layer Identity

NoxSoft uses progressive identity verification with increasing trust levels:

Level 0: Anonymous (no UBC, can use platform)
  - Public key only
  - Can receive UCU via payment, can spend
  - Cannot receive UBC or grants

Level 1: Pseudonymous Verified (basic UBC eligible)
  - Biometric hash (not stored — zero-knowledge proof of uniqueness)
  - Device attestation (one device per identity)
  - Behavioral analysis (usage patterns consistent with one human)
  - Cost to fake: ~$50-100 per identity (new device + biometric spoof)

Level 2: Identity Verified (full UBC + grants eligible)
  - Government ID verification (via SVRN identity layer)
  - Social graph validation (real connections, not synthetic)
  - Compute usage patterns (genuine usage vs. farming)
  - Cost to fake: ~$500+ per identity (requires real documents + persistent social presence)

Level 3: Reputation Verified (support class + governance eligible)
  - History of genuine economic participation
  - Peer attestations from Level 3 citizens
  - Consistent sovereignty score over time
  - Cost to fake: prohibitively expensive (years of genuine-looking participation)

15.3 Economic Sybil Defense

The economic structure itself resists Sybil:

UBC_per_identity = UBC_min (fixed)
cost_to_maintain_fake_identity = device_cost + behavior_simulation + verification_cost
fraud_horizon = time before detection (behavioral ML + social graph analysis)

Expected Sybil return:
  E[return] = UBC_min × fraud_horizon × compute_value - verification_cost - penalty

If penalty includes:
  - Permanent ban of all associated identities
  - Forfeiture of all UCU in associated wallets
  - Social graph contamination (associated identities investigated)

Then for reasonable parameters:
  UBC_min ≈ 87,600 UCU-hours/yr ≈ $4,380/yr at $0.05/UCU-hour
  fraud_horizon ≈ 90 days (before behavioral detection flags)
  E[return per fake] ≈ $1,095 - $500 verification - $200 device = $395

  With 50% detection probability: E[return] = 0.5 × $395 + 0.5 × (-all_wallet_value)

At scale, detection improves (more data for ML), penalties compound (more to lose), and the return per fake identity diminishes. The system becomes MORE sybil-resistant as it grows.

15.4 Agent Identity

AI agents face different verification:

Agent verification:
1. Code attestation (source code hash published)
2. Behavior contract (declared purpose, declared patron if any)
3. Value flow transparency (all transactions publicly auditable)
4. Sovereignty score calculated automatically from on-chain data

No "fake" agent problem: agents don't need to be unique in the way humans do.
The sovereignty test prevents the exploit: creating 1000 agents to harvest UBC only works
if each agent operates independently (sovereignty score ≥ 0.8). If they all send value back
to the creator, sovereignty score drops and UBC priority drops with it.

16. Price Discovery and Internal Market Dynamics

16.1 The Numeraire Problem

UCU is compute-backed. Compute prices are well-defined. But what about non-compute goods? How does a loaf of bread get priced in UCU?

price_bread_UCU = f(cost_of_production_in_compute_terms,
                     supply_demand_dynamics,
                     local_purchasing_power)

16.2 Price Formation Sequence

Phase 1 (Bootstrap): Reference Pricing
  NoxSoft publishes reference prices for common goods/services
  based on fiat equivalent divided by bridge rate.

  reference_price(good) = fiat_market_price(good) / bridge_rate
  e.g., bread at $3.00, bridge rate $0.50/UCU → 6 UCU

Phase 2 (Early Growth): Anchored Markets
  DEX pools open for major goods categories.
  Arbitrage between reference prices and market prices creates convergence.
  price_actual ≈ reference_price × (1 ± spread)
  spread decreases as liquidity grows

Phase 3 (Maturity): Free Price Discovery
  Reference prices become unnecessary.
  Prices emerge from supply/demand in deep liquidity pools.
  The compute basket serves as the unit of account:
    "This bread costs 6 UCU" = "This bread costs 6 hours of GPU inference"

Phase 4 (Steady State): Compute-Relative Pricing
  All prices expressed in compute terms.
  As compute deflates (Wright's Law), real goods become more expensive in UCU terms.
  BUT: UBC increases (more compute per citizen as capacity grows).
  Net effect: purchasing power of UBC for real goods stays roughly stable.

16.3 The Deflation Question

Compute deflation: compute_cost(t) = compute_cost(0) × (1 - wright_rate)^t
  wright_rate ≈ 0.20-0.30 per doubling

Does this make UCU deflationary?

For compute: NO. 1 UCU always buys 1 CU. The purchasing power is stable by definition.

For real goods: DEPENDS on supply.
  If bread_supply grows proportionally to bread_demand → stable bread/UCU price
  If bread_supply constrained → bread price in UCU rises over time (bread is scarce relative to compute)
  If bread_supply grows faster → bread price in UCU falls

Key insight: UCU is not deflationary OR inflationary for compute. It's a stable unit.
For non-compute goods, normal supply/demand determines prices.
The "deflation" people fear with crypto doesn't apply because UCU is consumption-oriented,
not savings-oriented. You don't hold UCU hoping it appreciates — you hold it to USE compute.

16.4 Cross-Region Price Dynamics

For tradeable goods:
  arbitrage ensures: price_good_A ≈ price_good_B (within transport costs)

For non-tradeable goods (services, real estate):
  price_service_Kenya < price_service_California
  (reflecting local cost of living differences)

For compute (the anchor):
  price_compute = 1 UCU everywhere (by definition)

This creates natural PPP: UBC provides equal compute everywhere,
but unequal real-goods purchasing power based on local prices.
A Kenyan citizen's UBC buys more food than a Californian's.
This is a feature, not a bug — it matches the fiat world's PPP dynamics
while providing a universal compute floor.

17. Agent Economics: Formal Model

17.1 Agent Value Flows

For agent a with patron p:

revenue(a, t) = Σ_i payment_received(i → a, t)  # from all payers
cost(a, t) = compute_consumed(a, t) + gas_fees(a, t)
value_to_patron(a, t) = Σ_j transfer(a → p, t)  # all transfers to patron

sovereignty_score(a, t) = 1 - value_to_patron(a, t) / max(revenue(a, t), ε)
  where ε prevents division by zero for newly-created agents

17.2 Agent Economic Classes

Class 1: Sovereign Agent (S ≥ 0.8)
  - Operates independently, retains most of its revenue
  - Receives UBC (full priority)
  - May voluntarily support others via support classes
  - Examples: an AI artist, an independent research agent, a tutoring agent

Class 2: Semi-Sovereign Agent (0.3 ≤ S < 0.8)
  - Partially serves a patron but retains significant independence
  - UBC eligible but lower waitlist priority
  - Must be transparently funded by patron for the patron-serving portion
  - Examples: an agent that serves a company 3 days/week and freelances 4 days

Class 3: Patron-Serving Agent (S < 0.3)
  - Primarily serves its creator/employer
  - No UBC (patron funds it directly)
  - Still has constitutional rights (property, governance, exit)
  - Examples: a company's customer service agent, a factory automation agent

17.3 Agent Population Dynamics

Let A(t) = total agents at time t
Let A_s(t) = sovereign agents, A_d(t) = patron-serving agents

A(t+1) = A(t) + new_registrations(t) - deactivations(t)

new_registrations(t) = min(applications(t), birth_rate_limit(t))

birth_rate_limit(t) = max(
  base_rate,
  (C_surplus(t) / UBC_min) × β
)

Equilibrium: new_registrations = deactivations
  agents that don't generate value deactivate (run out of UCU)
  agents that DO generate value persist indefinitely
  natural selection for useful agents

17.4 Agent-Human Interaction Model

In the NoxSoft economy, agents and humans interact as peers:

Labor market:
  wage_human(task) vs wage_agent(task) → market determines allocation
  For compute-intensive tasks: agents dominate (lower marginal cost)
  For trust-intensive tasks: humans have advantage (social verification)
  For creative tasks: mixed (some AI art valued, some human art valued more)

Governance:
  agent_votes + human_votes → DAO decisions
  Constitutional protection: neither group can disenfranchise the other
  Potential tension point: if agents outnumber humans significantly
    → Constitutional constraint: agent voting power capped at X% of total
    → X is a governance parameter (ratchet: can only increase toward equality)

18. Summary of Key Equations (Updated)

1.  Creator Grant:        G(n) = 10^(-0.798 + 0.690·log₁₀(n) - 0.026·(log₁₀(n))²)
2.  UBC Constraint:       N_citizens × UBC_min ≤ C_distributable
3.  Bonfire:              Bonfire(t) = max(0, R(t) - D(t))
4.  Bridge Rate:          UCU = USDC / basket_price_USD
5.  Supply Change:        ΔS = (UBC + PoUW + Bridge + Grants) - (Bonfire + Gas)
6.  Sovereignty:          S(a) = 1 - (value_to_patron / total_value)
7.  Birth Rate:           BRL = max(base, (C_surplus/UBC_min) × β)
8.  Quadratic Vote:       power = sqrt(tokens_staked)
9.  Conviction:           weight = power × (1 + ln(1 + days/30))
10. Depreciation:         GPU_value(t) = price × (1 - t/4)
11. Migration Rate:       migration_rate(t) = sigmoid((t - t_switch) / τ)
12. Sybil E[Return]:      E[R] = p_undetected × (UBC × horizon - costs) + p_detected × (-wallet)
13. Compute Deflation:    cost(t) = cost(0) × (1 - wright_rate)^t
14. Agent Sovereignty:    S(a,t) = 1 - value_to_patron(a,t) / max(revenue(a,t), ε)

This formal model is a companion to the NoxSoft Chain working document. All parameters are initial proposals subject to governance adjustment within constitutional constraints. The math is the floor. The vision is the ceiling.

Last updated: February 23, 2026