Islamic Finance Principles Assessment
Riba — Does c0mpute involve interest?
c0mpute's design does not center on interest-bearing lending or borrowing; its treasury is funded by real compute-service margins and trading fees, and staking rewards are variable USDC distributions rather than a fixed guaranteed rate. On its face this structure sits closer to profit-sharing than riba. Muslim investors should still confirm no third-party integration introduces interest-bearing instruments before treating any surplus as clean.
Assessment: Minor Riba
Score: 74.7/100
Our methodology examines 10 criteria to evaluate how well c0mpute avoids interest-based mechanisms.
Protocol revenue comes from two disclosed streams: a 30% margin retained from paid AI inference jobs, and 35% of ZERO trading fees, both routed into a single treasury. Neither stream is described as interest income, and there is no lending or credit-intermediation function at the base-protocol level — the network brokers GPU compute for USDC payment, not loans. The treasury itself is not described as holding interest-bearing instruments; it is split daily between buy-and-burn and staker distribution. Based on available sources, the revenue model is service-fee based rather than riba-based, though no independent financial audit confirms treasury composition.
Staking rewards are drawn directly from real network revenue (compute margins and trading fees), not from fixed interest or token emissions, and the payout amount fluctuates with actual treasury inflows day to day. This variable, performance-linked structure is meaningfully different from a fixed-rate deposit product and aligns more closely with profit-sharing than riba. A 24-hour deposit-aging rule before rewards count also tempers pure speculation-driven staking. However, sources do not disclose custody model, lock-up terms, or slashing conditions, so the full risk profile of the staking arrangement cannot be fully verified.
Gharar — How much uncertainty does c0mpute involve?
c0mpute carries moderate uncertainty: the team is named and credentialed, and the fee/burn mechanism is clearly documented, but core disclosures around audits, token distribution, and governance are missing. This mix of clarity in some areas and opacity in others is the defining gharar issue. Investors should treat the undisclosed items as real unknowns rather than assume they are benign.
Assessment: Moderate Gharar (Material Uncertainty)
Score: 51.3/100
Our methodology examines 15 criteria including team transparency, audit quality, and governance.
The team is named and traceable: CEO Albert Zhang (Delysium, Xsolla background), CTO Xingfan Xia (Apple, AWS, Airbnb data/AI experience), plus a named CBO and CLO, and the project holds NVIDIA Inception program status. This is a meaningfully stronger transparency baseline than anonymous or pseudonymous teams common in DeFi. However, open-source status of the codebase is not confirmed in available sources, and no long multi-year operating record, user metrics, or independent incident history exists yet to corroborate the team's claims beyond credentials and affiliation signals.
No security audit specific to c0mpute or the ZERO token was found in any retrieved source; audit-firm references located (including Halborn) all pertain to unrelated projects. This absence of a named, dated third-party audit is a genuine gharar concern and should be treated as such rather than assumed away. Additionally, governance rights, token distribution percentages, vesting schedules, and staking lock-up/slashing terms are undocumented. Mechanics that are described (fee splits, burn ratios, staking flow) are laid out clearly at docs.c0mpute.ai, but the absence of audit and allocation disclosure leaves real, unresolved uncertainty.
Maysir — Does c0mpute involve gambling or speculation?
c0mpute is not structured as a wagering or chance-based product; its core function is coordinating paid GPU compute jobs for AI inference. Speculative trading of ZERO on secondary markets can occur, as with any listed token, but this behavior is external to the protocol's own design. The underlying mechanism itself is productive rather than gambling-based.
Assessment: Moderate Maysir (High Risk)
Score: 57.5/100
Our methodology examines 11 criteria to determine whether c0mpute is a gambling instrument or a genuine economic tool.
The protocol connects GPU "worker" providers with users needing AI inference, charging in USDC for actual computational service rendered — a real economic function comparable to cloud computing marketplaces. Workers retain 70% of job value while the remaining margin funds the treasury, and ZERO itself is explicitly framed by the project as a value-accrual and incentive instrument rather than a required medium of exchange. This service-for-payment structure, tied to tangible compute delivery rather than chance outcomes, distinguishes c0mpute from maysir-style products where returns depend purely on random or zero-sum wagering.
Weighed together, c0mpute's genuine utility — real compute jobs, revenue-funded burns, and USDC-denominated staker distributions — gives it a productive foundation distinct from pure speculation. That said, as with most listed tokens, secondary-market trading of ZERO can attract short-term speculative behavior unrelated to the protocol's actual usage, and thin publicly available data on liquidity, market cap, or trading patterns makes it hard to gauge how dominant such speculation currently is. This external trading risk is a feature of markets generally, not a designed gambling mechanism within c0mpute itself.
The Full 27-Point Screening
1. Legitimacy (4 criteria)
| Criterion | Score | Analysis |
|---|
| Team Transparency | 75/100 | Team members are named with specific, checkable professional histories and the project is affiliated with the NVIDIA Inception program. |
| Fraud & Scam Risk | 55/100 | No fraud, hack, or rug-pull reports were found for c0mpute specifically, but the project's short track record limits confidence in this absence of evidence. |
| Use Case Legitimacy | 78/100 | Sources describe a working peer-to-peer GPU/AI compute marketplace with users paying in USDC for real inference jobs. |
| Ethical Practices | 82/100 | The protocol's own design is an AI/compute coordination network with no described connection to a prohibited industry. |
Summary: The team is named with credible, checkable professional backgrounds and NVIDIA Inception affiliation, though no fraud/hack history was found either way given the project's short track record.
2. Project Operations (9 criteria)
| Criterion | Score | Analysis |
|---|
| Core Protocol Business | 82/100 | The base protocol's business is decentralized compute/AI infrastructure, a sector not flagged as prohibited in the sources. |
| Transaction Fees | 72/100 | Fee flows are explicitly disclosed (worker 70%/treasury 30% margin, 35% of trading fees) with no interest-like extraction described. |
| Treasury Assets | 70/100 | Treasury is described as USDC accrued from real network revenue with no mention of interest-bearing placements, though full treasury composition is not detailed. |
| Revenue Model | 78/100 | Revenue is explicitly tied to compute-job margins and trading fees rather than any lending or interest activity. |
| Transparency | 45/100 | Token mechanics are documented in detail, but open-source status of the codebase itself is not addressed in the sources. |
| Governance | 30/100 (low evidence) | No source describes a governance structure, voting mechanism, or decentralization of control for c0mpute. |
| Launch Fairness | 35/100 (low evidence) | Launch fairness, presale terms, or insider allocation at token generation are not covered in any retrieved source. |
| Token Distribution | 30/100 (low evidence) | No breakdown of token distribution percentages among team, investors, or community was found. |
| Speculation/Utility Ratio | 55/100 | ZERO is explicitly described as a value-accrual/incentive instrument rather than the network's required payment token, indicating a real but secondary utility role alongside speculative trading and burn dynamics. |
Summary: c0mpute operates a described peer-to-peer AI/GPU compute network with clearly disclosed fee-splitting into a treasury, but governance structure, launch fairness, and token distribution/vesting details are undocumented in the sources.
3. Financial Health (4 criteria)
| Criterion | Score | Analysis |
|---|
| Protocol Revenue | 78/100 | Disclosed revenue sources (compute margin, trading fees) contain no interest component. |
| Financial Status | 30/100 (low evidence) | No market cap, price stability, liquidity, or listing data for ZERO appears in the sources. |
| Interest Assessment | 80/100 | The base protocol is described purely as a compute marketplace with no lending or borrowing function. |
| Audit Quality | 15/100 (low evidence) | No security audit report specific to c0mpute or the ZERO token was found among the retrieved sources; the Halborn materials present concern unrelated projects. |
Summary: Revenue comes from compute-job margins and trading fees with no lending or interest activity at the base protocol, but no market-stability data or any audit specific to c0mpute could be found.
4. Token Economics (5 criteria)
| Criterion | Score | Analysis |
|---|
| Token Purpose | 62/100 | ZERO is explicitly positioned as a non-payment, revenue-linked incentive/value-accrual token rather than a meme token with no function. |
| Governance Rights | N/A | No source mentions any governance rights attached to ZERO, and its absence is not itself flagged as a compliance concern. |
| Rewards Distribution | 82/100 | Rewards are explicitly variable, funded from actual treasury revenue (job margins and trading fees), not a fixed payout. |
| Speculation Controls | 55/100 | A 24-hour deposit-aging rule is the only disclosed anti-speculation feature; no other controls are described. |
| Asset Backing | 72/100 | Token value is tied to real, disclosed network revenue and a burn mechanism rather than pure speculative narrative. |
Summary: ZERO is explicitly a non-payment, revenue-linked value-accrual token with variable rewards tied to real network revenue, though governance rights and deeper anti-speculation design are unaddressed in the sources.
5. Staking Mechanism (5 criteria)
| Criterion | Score | Analysis |
|---|
| Mechanism Type | 50/100 | Direct staking with a 24-hour aging period is described, but custodial arrangement and unstaking terms are not specified. |
| Islamic Contract Classification | 55/100 | Rewards are revenue-shared from real economic activity resembling a profit-sharing structure, but the sources give no explicit Shariah-contract classification and the mechanism intertwines burns with staking rewards, leaving the classification unresolved. |
| Rewards Structure | 78/100 | Reward payouts explicitly vary with actual treasury inflows from compute margins and trading fees rather than being fixed or guaranteed. |
| Documentation | 65/100 | Official documentation at docs.c0mpute.ai explains staking mechanics and treasury splits, though risk and custody disclosures are incomplete. |
| Shariah Alignment | 52/100 | Revenue-based rewards reduce riba-like characteristics, but combined burn/speculative-trading dynamics and undocumented custody/slashing terms leave a degree of unresolved gharar. |
Summary: A native staking mechanism exists, paying real USDC revenue share and credit allowances with a short deposit-aging rule, but custody model, lock-up terms, and slashing are not documented in the available material.
Overall Assessment: c0mpute presents as a genuine, revenue-generating compute-network project with a reasonably transparent fee/treasury/staking design, but the absence of any confirmed security audit, governance disclosure, or distribution/vesting information leaves several Shariah-relevant gaps that these sources could not resolve.