AIGOX, short for Artificial Intelligence Go eXchange, is an open artificial intelligence collaboration network built on BNB Smart Chain. It connects AI models, intelligent agents, heterogeneous computing resources, task protocols, verification mechanisms and application-layer settlement into one coordinated digital infrastructure.
AIGOX follows a real-utility-first design principle, mapping every token function to an actual product action and ecosystem requirement.
Standardize descriptions of CPUs, GPUs, storage, bandwidth, geographic regions, latency and availability windows, allowing users to compare real computing capabilities rather than relying only on cloud provider product names.
The scheduling layer matches tasks with suitable nodes based on performance, price, latency, reliability, reputation and security requirements instead of simply selecting the lowest bid.
Signed receipts, result hashes, repeated execution, sampling validation, staking and dispute resolution transform service delivery into an auditable and settlement-ready collaboration record.
Requesters, providers, developers, validators, contributors and ecosystem partners form the foundation of the AIGOX market.
AIGOX uses a hybrid architecture to balance performance, privacy, cost efficiency and public verifiability.
AIGOX transfers, task escrow, settlement results, staking states, critical signatures, result hashes, governance proposals and execution records.
Model inference, training, raw user data, large output files, node discovery, real-time scheduling and monitoring indexes remain off-chain.
Data should only be submitted to the blockchain when public verification creates meaningful value, avoiding unnecessary cost, latency and privacy exposure.
AIGOX is an ecosystem utility token. It does not represent equity, debt, deposits or a promise of fixed returns.
Explore Allocation & Release Schedule →
Used for model inference, agent workflows, image and video generation, and computing resource rental.
Explore utility →Providers and validators may lock AIGOX to qualify for higher value tasks and strengthen service accountability.
Explore utility →Developers can earn usage-based income through models, intelligent agents, plugins, APIs and reusable workflows.
Explore utility →Eligible holders or participants may provide governance signals on budgets, parameters and protocol upgrades.
Explore utility →Service quotas, priority access, templates and developer tools.
Explore utility →Budgeted rewards for accepted data, testing, security and ecosystem work.
Explore utility →Supply, distribution, proposed cliffs and long-term vesting.
Explore economics →Each phase depends on product reliability, security review, operational readiness and governance preparation.
User research, architecture, legal structure, economic model and threat modeling.
Wallet connection, test token, node registration, task creation and simulated settlement.
Benchmarking, resource matching, container execution, result submission and basic reputation.
Smart contract audits, multisig rehearsals, monitoring, bug bounty and incident response.
BEP-20 token, treasury, vesting, settlement modules and production service deployment.
Continuous optimization around reliability, real demand, service revenue and transparent operations.
The whitepaper explains the market background, ecosystem modules, decentralized AI compute marketplace, task protocols, verification and reputation mechanisms, technical architecture, on-chain and off-chain boundaries, token economics, governance framework, security, privacy, application scenarios and development roadmap.
Download Whitepaper PDFThe access layer connects user experience to resource requirements, data permissions and settlement conditions.
Web, mobile and partner integrations should converge on the same task semantics. The interface may simplify resource selection, but it must not silently change the budget, data policy or acceptance conditions.
Access is therefore more than wallet connection: it is the point where identity, service permissions and a bounded task agreement meet.
{
"version": "design-example",
"taskId": "task-illustrative-001",
"resource": {
"accelerator": "GPU",
"minimumVramGB": 24,
"regionPolicy": "requestor-defined"
},
"budget": { "asset": "AIGOX", "max": "100" },
"deadline": "requestor-defined",
"validationPolicy": "acceptance-policy-hash",
"dataRef": "access-controlled-object-reference"
}Conceptual task envelope. Field names and values illustrate a design, not a published API contract.
| Interface | Primary audience | Controls that matter |
|---|---|---|
| Web / mobile | Service requestors | Inputs, quotation, deadline, result acceptance |
| Wallet | Asset authorization | Account, chain, signed action and spending scope |
| Developer console | Integrators and service authors | Task policy, service version, usage and receipt inspection |
| Partner API | Applications and workflow systems | Bounded authorization, repeatable request handling and reconciliation |
Separate data possession, access authorization, integrity verification and long-term availability.
rootₜ = MerkleRoot(leaf₁, …, leafₙ)
VerifyPath(leafᵢ, pathᵢ, rootₜ) = trueA Merkle proof establishes that a leaf is included in a committed set. It does not prove the truth of the underlying output, grant access to its data, or guarantee that the data remains available.
Batching can amortize the cost of recording commitments. The trade-off is additional waiting time before a batch closes and a need to keep proofs and underlying records retrievable. Data availability remains a separate operational obligation.
| Record | Storage / access boundary | Retention question |
|---|---|---|
| Model inputs and outputs | User-designated or controlled object storage | When does the service stop needing the object? |
| Execution logs | Restricted operational systems | Which fields are necessary for debugging and disputes? |
| Reputation summary | Privacy-safe index | Can a service measure be published without exposing raw user data? |
| Identity evidence | Restricted compliance process | Who can inspect it and under which purpose? |
| On-chain commitment | Public and persistent | Does committing this value reveal sensitive information indirectly? |
A task-to-node system that accounts for capability, time, locality and the cost of failure.
Filtering answers whether a node can run the task. Ranking answers which eligible node offers the best expected delivery. Combining the two into a single unbounded score can allow cheap but unsuitable resources to enter the schedule.
| Task / node | GPU-A | GPU-B | GPU-C | CPU-D |
|---|---|---|---|---|
| Image batch | 0.92 | 0.64 | 0.30 | × |
| Model inference | 0.51 | 0.88 | 0.72 | × |
| Video render | 0.39 | 0.46 | 0.91 | × |
| CPU analysis | 0.20 | 0.27 | 0.40 | 0.86 |
Ωⱼ = { i | capabilityᵢ ≥ requirementⱼ, memoryᵢ ≥ demandⱼ, availableᵢ = 1 }
min Z = α · Cost + β · Makespan + γ · CorrelatedRiskThe candidate set applies mandatory hardware, security and availability constraints. The objective then trades price, completion time and correlated failure risk. Weights are design parameters, not fixed production values.
| Condition | Scheduler response | Accounting consequence |
|---|---|---|
| Node unavailable | Reassign or resume from a valid checkpoint | Avoid charging twice for duplicated work |
| Deadline at risk | Re-estimate, notify or apply agreed fallback | Any increased budget requires authorization |
| Output mismatch | Hold acceptance and request validation | Do not finalize settlement on unaccepted output |
| Repeated retries | Stop at agreed retry or budget boundary | Escalate to refund or dispute policy |
Models, agents and compute become comparable when their units, limitations and acceptance conditions are explicit.
| Workload | Billable unit | Resource drivers | Acceptance evidence |
|---|---|---|---|
| Image / video | Image, duration or job | Resolution, model, VRAM, delivery speed | Output format, completion and agreed quality criteria |
| Model access | Tokens, requests or compute time | Model version, context size, concurrency | Usage receipt, response status and service policy |
| Agent workflow | Task, execution or runtime | Tool calls, iteration limit, operating duration | Step records, authorized actions and final deliverable |
| Compute rental | Resource × time | Accelerator, region, memory and availability | Reserved capacity, measured runtime and resource evidence |
C_task = C_compute + C_data + C_validation + C_settlement + C_recoveryA comparison must use the same completion and validation assumptions. A low hourly rate can be offset by slower execution, larger transfers or repeated failures.
Synthetic comparison. Segments show compute, data, validation/settlement and expected recovery cost. These are not network prices.
The on-chain layer coordinates assets and verifiable outcomes while keeping heavy computation off-chain.
A receipt connects a provider to a task and an output commitment. Verification must check not only the signature but also the expected signer, task status and acceptance policy. A cryptographically valid signature can still describe an unauthorized or stale action.
| Module | Responsibility | Control boundary |
|---|---|---|
| Token | BEP-20 transfers and fixed supply rules | No unrestricted discretionary minting |
| Treasury | Budget custody and authorized expenditure | Multisignature review and disclosed fund movements |
| Vesting | Time-based allocation release | Beneficiary schedule and limited administrative scope |
| Staking | Service accountability and penalty outcomes | Defined evidence, review and appeal rules |
| Settlement | Funding, acceptance, refund and payout | Task-scoped balances and authorized transitions |
| Governance | Parameter changes and upgrades | Review periods, timelocks and bounded emergency authority |
releasedⱼ + refundedⱼ ≤ fundedⱼ
SETTLED ⇒ validReceipt ∧ acceptedPolicy
DISPUTED ⇒ no further release until resolutionThese task-level constraints define what must remain true through success, retries and dispute resolution. They are design invariants, not a statement that deployed contracts have already been audited.
BNB pays blockchain transaction gas. AIGOX represents application-layer utility and settlement. A task budget and the wallet’s gas balance are distinct resources and should be presented separately.
Different workloads require different evidence. Verification cost, detection probability and reputation must be evaluated together.
Sampling trades verification cost against the probability of observing an invalid result. The curve below models independent samples drawn from a population with a fixed fault rate. It is a mathematical scenario, not measured network performance.
P_detect = 1 − (1 − f)ᵏ · k ≥ ln(1 − P_target) / ln(1 − f)f is the assumed fault rate and k the independent sample count. Correlated faults, selective attacks and biased sampling invalidate the simple independence assumption. More samples do not correct a poorly specified acceptance policy.
| Work type | Primary checks | What the checks do not prove |
|---|---|---|
| Deterministic computation | Hash comparison, recomputation, redundant execution | A matching hash does not establish that the input or task specification was correct |
| Generated AI content | Format, quality measures, requestor acceptance | Semantic correctness cannot generally be reduced to byte-for-byte equality |
| Continuous service | Availability, latency, response status, recovery | A healthy average can hide concentrated outages or tail-latency failures |
| High-value disputed work | Independent recomputation and review | Majority agreement alone does not rule out correlated providers |
A contribution economy built around accepted work, inspectable evidence and bounded incentives.
A contribution becomes rewardable when its value can be demonstrated, its evidence can be reviewed, and its claim can be distinguished from duplicate activity.
Illustrative shares only. They are not official allocation weights or a scheduled payout.
sᵢ = eᵢ × uᵢ × qᵢ × aᵢ · rᵢ = B × sᵢ / ΣⱼsⱼIllustrative model: e is binary eligibility; u is useful work; q is quality; a is an anti-abuse adjustment between 0 and 1. B is the approved distributable budget. If total eligible score is zero, no payout is calculated. Final weights, caps and review rules remain to be specified.
| Track | Reward basis | Review evidence | Failure mode |
|---|---|---|---|
| Compute supply | Completed, valid work | Accepted receipts, useful availability | Idle-capacity inflation; duplicate task claims |
| Developer services | Genuine adoption | Paying users, retention, service reliability | Self-funded usage loops; synthetic users |
| Data & evaluation | Accepted deliverables | Review scores, provenance, reproducibility | Duplicate datasets; unverifiable provenance |
| Security & testing | Validated findings | Reproduction steps, severity and remediation value | Duplicate reports; unverifiable impact |
| Community support | Useful ecosystem work | Accepted documentation, support outcomes | Spam; volume without measurable benefit |
Identify the task or deliverable, the contribution category, the acceptance criteria and evidence references. A stable claim identifier makes duplicates detectable.
Check acceptance, ownership or provenance, repeated claims and suspicious coordination. A large number of accounts must not substitute for independent value.
Separate accepted amounts from amounts under review. Publish the reason category and an appeal path without exposing sensitive evidence.
Record the approved payout, its budget period and the final status. Aggregate distributed, withheld and unused amounts so the period can be reconciled.
Developer monetization connects clear service terms, reliable execution and sustainable unit economics.
Gross usage is not developer income.
Compute, verification, operations and unsuccessful execution can change the economics of a seemingly successful service. Model the accepted task, then account for the work required to produce it.
Contribution margin = price − compute − validation − platform − expected retry costIllustrative operating model. The actual split is defined by service and task agreements; these are not fixed network fees.
Other modeled costs: validation 0.5, platform 0.5 and expected retry cost 0.5.
Contribution margin25.0% of revenue
| Before publication | At execution | After delivery |
|---|---|---|
| Version, capabilities and known limitations | Bind the request to a service version | Return outputs and an inspectable usage receipt |
| Input/output schema and pricing unit | Track billable units consistently | Reconcile agreed fees and accepted units |
| Data handling and retention policy | Constrain tools and data access | Apply disclosed retention or deletion rules |
| Acceptance and dispute criteria | Record relevant execution evidence | Review failures and update reliability history |
A staged governance system connects participation to narrowly defined, reviewable and accountable actions.
Accountable deployment, incident response and initial budgets. Public signer policies and authority boundaries establish who can act and what they can change.
Discussion and signaling collect preferences. Proposal thresholds and clear scopes make review manageable before authority transfers.
Treasury actions, upgrades and suitable parameters enter an execution queue with review time and verifiable transaction details.
Councils or a DAO may administer mature modules under defined mandates, conflict rules and limits on emergency authority.
| Component | What it needs to specify | Why it matters |
|---|---|---|
| Scope | Module, parameters and intended behavior change | Prevents a broad mandate from hiding unrelated changes |
| Budget | Amount, recipient, asset and spending purpose | Connects the vote to an inspectable fund movement |
| Execution | Exact authorized action and timing | Distinguishes a sentiment signal from a binding operation |
| Risk review | Dependencies, failure cases and recovery approach | Makes security assumptions visible before execution |
| Outcome | Execution status and follow-up metrics | Allows the community to compare intent with results |
Service allowances, tools and participation rights require clear eligibility, metering and lifecycle rules.
| Benefit dimension | Entitlement meaning | Enforcement boundary |
|---|---|---|
| Service quota | A defined allowance of eligible service units | Meter by a documented unit and reset period |
| Priority access | Scheduling preference where permitted | Does not override resource, privacy or security constraints |
| Exclusive templates | Access to designated models or workflows | Version and usage scope remain explicit |
| Developer tools | Console, templates or integration capabilities | Role-based permissions and bounded credentials |
| Participation eligibility | Access to specific ecosystem processes | Separate governance, service and identity requirements |
Service credits consumed
This is an explanatory example, not an available plan. Credits should map to a defined service allowance. They must not be presented as a guaranteed cash value or financial return.
Consumption, expiry and rollover rules need to be visible before a user commits to an entitlement.
Budget reservation, delivery acceptance and fee distribution are separate stages of one auditable settlement.
| Movement | AIGOX |
|---|---|
| Reserved budget | 100 |
| Accepted provider compensation | −70 |
| Developer fee | −15 |
| Validation / service fees | −5 |
| Unused balance returned | −10 |
| Unreconciled balance | 0 |
100 = 70 + 15 + 5 + 10Synthetic amounts demonstrate reconciliation. They are not published fee percentages.
The reserved budget is a ceiling, not an instruction to spend the full amount. A successful task can settle below the maximum, with any remaining balance handled under the task agreement.
| Trigger | Operational action | Balance handling |
|---|---|---|
| Unavailable provider | Reassign within agreed limits | Preserve the authorized budget |
| Invalid output | Recompute or dispute | Withhold unaccepted payment |
| Deadline exceeded | Apply task policy | Partial refund or review where appropriate |
| Requester rejects | Check agreed acceptance criteria | Review evidence before release or refund |
Stake supports accountability when the evidence, exposure and review process are all explicit.
Collateral raises the cost of violating service rules, but its effect depends on the chance of detection, the amount actually exposed to loss and the quality of the review process.
Locking a large balance cannot replace independent verification. Conversely, disproportionate exposure can discourage capable providers from joining.
U_attack = G_attack − P_detect × S_exposed − C_attackG is the potential gain, P the probability of detection, S the stake that can actually be lost under the rules, and C the cost of carrying out the attack. This expected-value model is a simplification, not a complete security guarantee.
Example attack gain: 400 AIGOX. Attack cost: 50 AIGOX. No actual stake requirement is implied.
Expected loss exceeds the modeled gain.
Benchmark resources and inspect supported workloads. Determine whether the provider meets the service’s minimum operational requirements.
New providers take smaller or lower-risk workloads so performance evidence can develop before higher-value work is assigned.
Distinguish ordinary failure, misrepresentation and malicious behavior. An unavailable node and a forged result should not automatically receive identical treatment.
Use defined evidence and review rules before material penalties. Record outcomes and provide a process for correcting an erroneous decision.
A transparent capital structure, with time-based vesting separated from performance-based distribution.
Allocation describes intended use, not immediate circulation. Treasury balances, vested balances, deployed liquidity and freely transferable balances answer different questions and must be reported separately.
Inspect the proposed linear schedules for product development, team and advisory allocations. Incentives, treasury and liquidity are excluded from this curve because their releases depend on budgets, milestones or deployment decisions.
Vᵢ(t) = Aᵢ × clamp((t − cᵢ) / dᵢ, 0, 1)Aᵢ is the allocation, cᵢ the cliff and dᵢ the linear release duration. This explorer assumes continuous vesting begins after the cliff, with no catch-up release. The eventual contract defines exact timing and claim rules.
| Allocation | Amount | Proposed release | Decision evidence |
|---|---|---|---|
| Ecosystem | 3.5B | At least 48 months | Quarterly budget, accepted activity and anti-abuse review |
| Treasury | 2.0B | Proposal / budget approval | Purpose, recipient, amount and execution record |
| Product & R&D | 1.8B | 6-month cliff + 36 months | Delivery milestones and vesting terms |
| Team | 1.2B | 12-month cliff + 36 months | Continued service and vesting terms |
| Liquidity | 1.0B | Progressive deployment | Launch plan, depth and reporting |
| Advisory | 0.5B | 6-month cliff + 24 months | Verifiable strategic deliverables |