Trixta Tokenomics — Foundation Model

Maintained by: Trixta Foundation (non‑profit, to be incorporated as a Swiss Stiftung in Zug, Switzerland)

Contact: foundation@trixta.org • security@trixta.org
Network: Solana
Settlement currency: USDC (native)
Epoch cadence: 1 hour
Weekly operator window: Wednesdays 8:00 AM–12:00 PM ET (12:00–4:00 PM UTC)
Time standard: All times shown in ET (observes EST/EDT).

Status: Proposed (Pre‑Launch) Draft. The details below describe how the Trixta network is designed to operate and may be refined by the Trixta Foundation prior to launch.

Plain‑English notice. This page describes how the Trixta network is designed to operate. It is not an offer of securities or a promise of price, profit, or yield. Parameters shown are governance‑tunable and may change via on‑chain votes with public change logs. Prior to launch, the Foundation may adjust parameters to address security, compliance, or operational readiness. 

1) What Trixta does

Trixta routes workloads across decentralized compute (DeCloud nodes), local Wasm, and SaaS APIs, with policy‑based routing for cost, latency, and privacy. Users pay in USDC; only the decentralized compute slice is tokenized.

 

  • Users / Spaces: Deposit USDC, submit jobs, settle on completion.
  • Operators (CPUs/GPUs): Stake Trixta (TRIX) to advertise capacity and SLO tier; fulfill jobs; get paid USDC + TRIX.
  • Verifiers / Oracles: Attest receipts, SLOs, and anomalies; their work gates minting and slashing.
2) The core model (at a glance)

Hybrid design:

 

  1.  Work‑Token staking (supply security). Operators stake Trixta (TRIX) to participate; poor performance is slashable.
  2. Burn‑and‑Mint on DePIN only (demand linkage). When jobs run on decentralized compute, the protocol burns TRIX proportional to USD spend for that epoch and mints a fraction to reward supply.
  3. Programmatic buybacks + insurance. A portion of protocol margin funds buybacks (burned) and an insurance pool for job failures.
Why this works: users get a clean USD UX, while the token captures only the crypto‑native part of the system (decentralized compute supply and its verifiers).
 
3) Payments & user experience
  • Users pre‑fund USDC balances. Jobs are quoted in USD, settled in USDC.
  • Routing chooses SaaS / Wasm / DeCloud per policy (cost, latency, privacy).
  • Only DeCloud jobs drive burns/mints; SaaS/Wasm jobs pay normal fees (supporting insurance and buybacks).
 
4) Operator incentives
  • Payout split: 80% USDC / 20% TRIX (TRIX auto‑staked; 7‑day unbond).
  • SLO tiers: Gold (higher reliability) earns higher TRIX multipliers and requires more stake; Silver (base); Bronze (discounted).
  • Weekly optional conversion window: Operators may convert a small portion of that week’s TRIX rewards to USDC at a 24‑hour TWAP with a modest haircut. A governance‑capped share of the buyback budget funds this OTC window; the rest executes market buybacks.

5) Burns & Mints (BME on DeCloud)
Per 1-hour epoch:
  • Burn: USD spent on DeCloud jobs is translated (via a TWAP) into TRIX burned.
  • Mint: The protocol mints r × burn to reward supply.
    •  Initial r: 0.40 (deflationary bias)
    • Target r (when metering is stable): 0.60
    • Governance‑tunable with daily rate‑limits to prevent whiplash.
  • Distribution of mints: ~95% to operators (pro‑rata, QoS‑weighted), ~5% to verifier/restaker roles.
  • Accounting: Usage burns (drive mints) and treasury buyback burns (do not drive mints) are tracked separately for transparency.
6) Staking & slashing (supply security)
  • Stake per unit scales by hardware class (H100, A100, L40S, 4090, vCPU) and by SLO tier.
  • Composition: At least 30% must be liquid TRIX; up to 70% can be non‑transferable bootstrap stake credits (fully slashable; convert 1:1 to liquid TRIX after sustained SLO‑compliant service).
  • Slashing: Minor SLO misses incur small stake penalties (capped); repeated or fraudulent behavior is penalized more and can trigger auto‑quarantine (routing paused) until restaked.
 
7) Oracles & safeguards
  • External prices (independent): Pyth is primary with Switchboard fallback. We use TWAPs with staleness/confidence checks and divergence guards before any price is used for burns, mints, or OTC pricing. If feeds are unhealthy, actions are paused and retried—jobs and USDC payouts continue.
  • Internal facts (Trixta Oracle Layer): Decentralized reporter committees on Trixta aggregate usage, verify SLO/QoS, and flag anomalies. Their EpochReports gate minting alongside the price oracles. A “shadow price” comparator can pause sensitive actions if DEX prices diverge materially from oracle prices.
 
8) Treasury, buybacks & insurance
  • A governance‑set portion of non‑DeCloud router margin (initially about one quarter, tunable within a published range) funds:
    1. OTC operator conversions (a capped share of the above budget), then
    2. Programmatic market buybacks (burned).
  • An insurance pool is funded from DeCloud spend and router margin; it can auto‑compensate a portion of verified failures, with larger events reviewed by governance.
 
8A) Programmatic Revenue Buyback-and-Burn (RBB) Mechanism
  • A portion of protocol surplus revenue is allocated to a rule-based Buyback-and-Burn module (“RBB”). This mechanism is fully programmatic, non-discretionary, and operates under transparent, governance-tunable parameters.
  • Revenue Pool. Non-DeCloud routing margin, platform fees, and other protocol revenues are pooled in USDC and allocated per epoch:
    • X% → Operator OTC conversion window
    • Y% → Programmatic buybacks (burned)
    • Z% → Insurance pool
(X + Y + Z = 100%; parameters rate-limited.)
 
  • Buyback Execution. 
    • Buybacks are executed automatically against TWAPs using approved venues with staleness and divergence guards.
    • Purchases are sent directly to a burn address.
    • Buyback burns do not trigger minting and are accounted separately from usage-driven burns.
  • Pauses & Safeguards.
    • Buybacks automatically pause under oracle health failures, liquidity thresholds, or governance timelocks to prevent manipulative behavior.
    • Pauses do not affect user job routing or operator payouts.
  • Transparency.
    • All buyback parameters, revenue flows, and burn totals (usage vs buybacks) are
      published in real-time dashboards.
    • Governance can modify allocation percentages subject to rate-limits and
      timelocks.
9) TRIX‑R (foundation raise class)
  • What it is: A redeemable class (SPL Token‑2022) with Transfer Hook controls; redemptions are at NAV, subject to eligibility and policy, from a ring‑fenced treasury held in conservative, on‑chain, short‑duration assets. Eligibility standards and transfer controls will reflect applicable Swiss and international regulations and Foundation policy.
  • What it is not: TRIX‑R does not receive protocol mints or buyback flows; it is ring‑fenced and does not vote in governance.
  • Liquidity & risk: The treasury maintains a liquid buffer, publishes composition in real time, and undergoes periodic attestations. Eligibility and KYC may apply depending on jurisdiction.
 
10) Governance & decentralization
  • Day‑1: 3‑of‑5 multisig with a 24‑hour timelock controls treasury/oracle/policy changes; an emergency pause exists for critical failures (with strict scope and sunset).
  • Planned DAO migration: After sufficient usage and security data, the Foundation intends to migrate to a Realms (SPL Governance) DAO (link coming soon). Indicative KPI gates include weekly DeCloud spend, active capacity, reliability, liquidity depth, and attribution coverage.
  • Voter alignment: Staked TRIX governs; optional time‑locks can boost voting weight (no extra yield). Parameter changes are rate‑limited by the programs to prevent governance whiplash.
     
11) Parameters (initial; governance‑tunable)
The following reflect current launch settings and may evolve via on‑chain governance subject to program rate‑limits.
  • Operator payout split: 80% USDC / 20% TRIX (TRIX auto‑staked; 7‑day unbond)
  • Mint ratio r: start 0.40; target 0.60 (with daily change limits)
  • OTC operator window: Wed 8:00 AM–12:00 PM ET; 24‑hour TWAP pricing with a modest haircut; per‑operator cap applies; global cap is a small fraction of the weekly buyback budget; remainder executes market buybacks
  • Stake (per 24/7 unit): H100 2,500 • A100 1,600 • L40S 800 • 4090 600 • vCPU (16‑core pack) 150 (× SLO multiplier)
  • Liquid stake minimum: 30% of required stake
  • Insurance funding: small percentage of DeCloud spend + router margin (published in dashboards)
  • Oracles: Pyth primary, Switchboard fallback; TWAPs with health checks and divergence guards
  • Accounting transparency: Burns from usage vs treasury buybacks are tracked and published separately
 
12) Transparency & change management
  • Dashboards (link coming soon): Burns by bucket (B_usage vs B_treasury), mints, r and rate changes, USDC spend split (DeCloud vs non‑DeCloud), OTC window requests & fills, oracle health (source, staleness, confidence), insurance funding & payouts.
  • Change logs (link coming soon): Any parameter change is published with rationale, vote links, and effective times.
  • Audits & attestations (program link coming soon): Smart contracts and treasury venues undergo periodic reviews with public reports.
 
12A) Security & responsible disclosure
  • Emergency‑pause scope: May pause burns/mints and OTC pricing; does not halt user job execution or USDC payouts. Pauses sunset unless ratified by governance. 
  • Audits cadence: External security reviews of programs; treasury venue attestations; public postmortems for incidents. 
  • Contact: security@trixta.org (PGP key and bounty policy — link coming soon).  
 
12B) Key risks (non‑exhaustive)
  • Oracle health: If primary and fallback feeds are unhealthy or diverge, sensitive actions pause; prolonged pauses can delay burns/mints and OTC pricing.
  • Attribution faults: Incomplete or late EpochReports pause minting until corrected.
  • Liquidity: Thin DEX liquidity may widen TWAP error bounds, increasing pauses.
  • Governance capture/whiplash: Mitigated via rate‑limits and timelocks but still a risk.
  • Regulatory uncertainty: TRIX‑R eligibility, transfer controls, or disclosures may evolve with law. 
 
13) Frequently asked questions

Why not make all jobs pay in TRIX?

Because users need stable, predictable pricing. We keep the token focused on securing decentralized supply and linking value to that usage.
 
Can operators avoid token exposure?
Yes—most cash flow is paid in USDC. The TRIX portion is auto‑staked with a short unbond, plus an optional weekly OTC conversion for a small slice.
 
How do you prevent gaming of mints?
Per‑job receipts, randomized audits, restaked verifier committees, and strict gating: no minting without both a healthy price feed and a valid EpochReport.
 
Does TRIX‑R affect TRIX supply?
No. TRIX‑R is ring‑fenced for redemptions at NAV and does not drive mints or buybacks.
 
14) Legal disclaimer

The Trixta Foundation (a Swiss non‑profit Stiftung to be incorporated in Zug, Switzerland) publishes this tokenomics model for informational purposes only. Nothing herein constitutes an offer to sell or a solicitation to buy any token, security, or financial instrument, nor does it constitute a prospectus or key information document under Swiss or other laws. Forward‑looking statements (including planned parameters and roadmap items) are subject to change by governance and program safeguards. Eligibility, KYC/AML, and jurisdictional restrictions may apply to certain instruments such as TRIX‑R. Use of the network is at your own risk.

Governing law & venue (site terms placeholder): To the extent applicable, matters relating to this page and Foundation disclosures are intended to be governed by Swiss law with a venue in Zug, Switzerland (subject to final counsel review).

 Data protection: Foundation data practices are intended to comply with Swiss FADP and other applicable privacy laws.

 
15) Glossary (quick)
  • Trixta (TRIX): The network’s utility token used for staking and supply incentives.
  • TRIX‑R: Redeemable raise class with Transfer Hook controls; ring‑fenced treasury; no governance rights.
  • BME (Burn‑and‑Mint Equilibrium): Mechanism where usage burns TRIX and a fraction is minted to reward supply.
  • SLO (Service Level Objective): Reliability/latency targets that affect pricing, stake, and rewards.
  • TWAP (Time‑Weighted Average Price): Averaged price over a window used for settlement and accounting.
 
Download:
Download PDF