Whitepaper

1. Introduction

A product that combines several AI capabilities often requires separate accounts, API keys, balances, documentation and integrations. A workflow involving search, a language model, image creation and video generation can involve several providers before it delivers a useful result.

Ace Data Cloud addresses this fragmentation with a shared gateway and service ecosystem. Teams can integrate supported services through common account and billing infrastructure while retaining the endpoint-specific contracts required by each capability.

For software that needs to pay per request, the documented keyless x402 flow offers an alternative to provisioning a platform account and API key. An agent or application can respond to a payment requirement, sign an accepted authorization and obtain a supported result after verification. Payment access is still subject to the request’s accepted terms and applicable controls.

The platform and token have different jobs. The platform delivers AI services. ACE provides defined holder benefits and is the asset purchased and burned under the qualifying-receipt policy. Platform activity does not create an automatic entitlement to token appreciation.

2. The Platform

Ace Data Cloud provides access to a changing catalog of AI services. Available models, parameters, modalities and prices should be checked in the live catalog and endpoint documentation. This whitepaper does not freeze a model count or claim that every service is cheaper than every official provider.

Classic use is metered through Credits, with service-specific or general balance arrangements where supported. Credits and ACE are not interchangeable. Credits are a platform usage accounting unit; ACE is an on-chain token. Purchasing ACE does not automatically fund a platform balance.

2.1 Ace Studio

Ace Studio is the browser workspace for using AI without implementing API calls. Users can work with capabilities such as chat, images, music and video through a shared interface. The features available to a user depend on the selected service, account permissions and any connected tools.

2.2 Developer surface

The developer ecosystem includes SDKs, command-line tools and MCP servers. These support typed integrations, scripted workflows and tool access from compatible assistants. The current documentation and public repositories provide the implementation reference. Authorization for a connector is scoped; it does not give blanket permission to publish, purchase or transfer assets.

2.3 Workflows and Dify

OpenAI-compatible chat interfaces can be used in compatible workflow tools such as Dify. Other modalities require their documented integrations or endpoints. Compatibility does not mean that every catalog service automatically becomes a supported node in every workflow tool.

2.4 Agent Skills

Agent Skills are instruction packs that help compatible assistants use the platform’s APIs and connected tools. They explain parameters, workflows and limitations. They complement credentials and permissions rather than replacing them. The available skills and supported environments can evolve independently of this whitepaper.

2.5 Nexior

Nexior is the open-source template for building branded AI experiences on the platform. Builders can adapt the interface and connect the appropriate services. Operating a branded product also requires pricing, support, privacy and compliance decisions; the template does not guarantee a profitable business.

3. Live Usage and Reporting

The platform operates AI services and provides usage and billing records. Product reporting should distinguish registered accounts, active users, successful requests, paid orders and revenue. These measures describe different parts of the business and should not be substituted for one another.

Usage and revenue figures in earlier editions, including August 2026 observations, are historical rather than current October performance. Current reporting should include a dated source, measurement period, definition and currency. The public Roadmap provides dated API usage, completed-order revenue and monthly revenue dashboards.

The public ACE ledger provides a more narrowly defined production record for the payment-linked mechanism. A dated snapshot is included in Section 7. It is evidence of specified receipts and token operations, not a substitute for a complete platform revenue report.

4. x402: The Keyless Rail

x402 uses HTTP 402 payment requirements to support paid requests. In the documented keyless flow, the caller sends a request, receives an accepted payment requirement, signs the corresponding authorization and retries with proof. The supported service responds after the payment flow is verified. No platform account or API key is required for that documented flow.

Exact settles the accepted amount for a supported request. Upto supports bounded metering on supported endpoints. The request’s actual payment requirements are authoritative. Solana devnet is a test option, not a production rail. A merged integration for another chain must not be described as live without production activation and settlement evidence.

Classic Credits billing and x402 coexist. The ACE holder discount applies only to supported Credits API consumption, not x402 USDC payments. Wallet ownership verification for holder benefits is separate from signing a payment or granting continuing payment authorization.

5. The $ACE Token

The full mint address identifies the token. Names, symbols and logos can be copied. The current SPL mint has no mint authority, so new tokens cannot be minted under its present configuration. Burns can reduce outstanding supply. These properties do not guarantee price stability, liquid markets or economic returns.

Earlier editions described a Pump.fun fair launch without a presale, migration to PumpSwap and burned launch LP tokens. These remain historical project disclosures, not newly verified transaction-level findings in this edition or a guarantee that every liquidity position is permanently inaccessible.

This document does not establish a new token, cross-chain migration, fixed allocation pie chart or vesting entitlement. Such changes require separate approved disclosures. A single wallet balance does not establish total project holdings or circulating supply.

6. Token Utility

6.1 Nine holder tiers

Holder tiers are determined from eligible ACE holdings in the verified wallet. The current schedule replaces the six-tier description in version 1.1. The discount and referral columns describe different benefits with different qualifying conditions.

Referral bonuses are subject to valid orders, account eligibility and current program rules. The final rate for a single beneficiary is capped at 30%. Holder tiers T1–T9 are not the affiliate-level schedule L1–L13.

6.2 Discount coverage

Discounts are configured per service and apply only to supported Credits API consumption. They do not apply to recharge orders, x402 USDC payments or other non-Credits consumption paths. Check the benefits center’s eligible-service list and the applicable service discount rather than assuming full-catalog coverage.

Example: if an eligible call would otherwise consume 100 Credits, an applicable 5% discount reduces consumption to 95 Credits. This is an illustrative usage calculation, not a fixed dollar conversion or a discount on the preceding top-up.

6.3 Wallet verification and eligibility

A user connects the Solana wallet holding the official token, signs the displayed ownership-verification message and waits for finalized-balance synchronization. ACE remains in the user’s wallet. The holder program does not require depositing, staking, locking or transferring tokens to the platform. Ownership verification does not authorize a payment.

Eligibility depends on fresh verified holdings. The balance-validity window checked on October 2, 2026 was 30 minutes. A successful synchronization after ACE is sold or transferred recalculates the tier. If the verified balance becomes stale, holder discounts and referral bonuses are not applied until it is refreshed. Browser disconnection does not by itself remove the platform binding; use the account unbind flow to replace the benefits wallet.

6.4 Holder referral commission bonus

Eligible promoters who hold ACE receive an addition to their own applicable referral commission rate when an attributed customer completes a qualifying order. This rewards platform promotion, not recruiting token buyers or simply holding ACE. The production mechanism was verified enabled on October 2, 2026, with existing commission records containing nonzero holder bonuses.

The final commission rate is the applicable base rate plus the holder bonus, capped at 30% for each beneficiary. Bonuses are added in percentage points, not as a multiplier. For example, a 10% base rate plus the T4 bonus of 1 percentage point gives 11%. The cap is a limit, not a promised rate.

Under the current two-level referral rules, if there is an eligible upline, the base commission pool is split 80/20 before holder bonuses are applied. The direct promoter and upline each use their own eligible holder tier. The 30% cap applies to each beneficiary, not to their combined commission.

A production settlement record dated October 2, 2026 showed a T6 beneficiary with a 20% base rate, a 2-percentage-point bonus and a 22% final rate. This is evidence of recorded commission calculation, not proof of a completed cash withdrawal or a promised rate for another account. No customer or wallet identifiers are disclosed here.

Commissions come from valid qualifying orders in the Finished state. Link clicks, registration, ordinary API calls and token ownership alone do not generate a new commission. Attribution, account eligibility, refunds, cancellations and risk controls still apply. Tier and rate snapshots are recorded at settlement; later holdings do not automatically rewrite historical orders. Check the referral rules and your actual account settlement records for applicable terms.

6.5 Selected-release early access

The implemented mechanism can allow verified T1+ holders to access configured services or features up to 72 hours before general availability. It relies on trusted tier checks, release-specific policies and time windows. The September implementation record explicitly says production policies and flags were not activated by that merge.

Early access must therefore be described as conditional by release. Each named release needs confirmation of its enabled policy, minimum tier, dates, billing and limits. A catalog listing, campaign draft or merged PR alone does not prove a live entitlement.

Early access does not automatically mean free usage, permanent exclusivity, priority queues or higher rate limits. Normal billing applies unless a specific approved offer says otherwise.

6.6 Benefits center and privacy

The holder benefits center uses backend tier information and benefit states, with tier progress, savings information and a Credits savings calculator. Public holder status is opt-in. Discounts, referral bonuses and early access are distinct entries, not interchangeable promises.

7. ACE Capital Policy

7.1 Payment-linked buying and burning

Once a qualifying USDC payment through x402 on Solana is confirmed, Ace Data Cloud sets aside 3% of the amount received to buy ACE on the market and burn the tokens purchased. This applies both when a customer buys platform Credits with USDC and when they pay directly for API usage through this payment rail.

For example, a qualifying purchase of Credits paid with 10,000 USDC creates a 300 USDC buy-and-burn budget. Spending those Credits later does not trigger another allocation: the USDC payment is counted once, when the Credits are purchased. The amount of ACE bought and burned depends on the market price and available liquidity.

The transparency tracker separates money set aside, ACE purchased and ACE actually burned. An allocated budget is not a completed burn, and tokens bought are not counted as burned until the burn transaction is finalized on-chain. Tokens retained in project wallets, liquidity deposits and test transactions are reported separately.

7.2 Historical inventory and retired allocations

Previously acquired ACE remains disclosed project inventory. The current policy applies to qualifying new receipts and does not turn historical holdings into retroactive burn obligations. Retained inventory does not replace or reduce the new allocation. Future uses should be disclosed when approved.

The earlier standalone allocations of 2% of Platform Revenue and 10% of Creator Fees have been discontinued. They must not be added to the new 3% qualifying-receipt budget. Historical records retain the labels applicable at the time.

7.3 Transparency and capital management

Platform income supports infrastructure, engineering, operations, growth and reserves. The public tracker separates production token activity, historical purchases, retained inventory and disclosed project wallets. The team wallet and retained inventory can refer to the same address and must not be counted twice. A wallet balance does not prove a lock or vesting schedule.

Dated production example. The transparency snapshot at 2026-10-02T15:28:08.920677+00:00 reports four qualifying payments totaling 25.9 USDC, a 0.777 USDC allocation and expenditure, and 2,849.523211 ACE acquired and burned across four completed production batches. It reports 533.275589 ACE in canary burns separately. These figures are observations at that timestamp, not forecasts or permanently current totals.

The policy introduces no staking rewards, passive yield or general distribution of platform income to token holders. It does not guarantee token appreciation.

8. Open Ecosystem

Ace Data Cloud supports builders through APIs, SDKs, MCP servers, Agent Skills, x402 clients and the Nexior template. The ecosystem allows developers to integrate capabilities, publish tools and build branded products. The available components and their contracts should be checked in the maintained repositories.

The Revenue Alliance referral program is distinct from the token’s supply mechanics. Qualifying promoters may earn commissions under valid-order rules, and eligible holders may receive the additional tier bonus. This is activity-based compensation, not income earned simply by holding ACE.

Ecosystem programs should state their rules, scope, eligibility and funding explicitly. This edition does not promise automatic creator-fee grants, exchange listings or rewards for speculative activity.

9. What Comes Next

Future work should deepen useful platform access, reliable integrations and documented holder value. Features enter the whitepaper as live benefits only after activation and evidence, not simply because implementation appears in a roadmap or merge log.

The public Roadmap tracks delivery separately from this whitepaper. Scope and timing are not contractual commitments. Current program rules and production evidence take precedence over older narrative descriptions.

Sources

Rules and evidence reviewed on October 2, 2026. Dated observations are not permanently current totals. Account eligibility and actual settlement records remain authoritative for individual benefits.

Holder benefits: ACE holder guide, benefits center, referral rules, and public feature configuration. The referral status in this edition also reflects a read-only production check of activation and anonymized commission records; it does not assert completed withdrawals.

Implementation history: the canonical September 12 updates and September 13 updates. A merge record alone is not evidence of production activation.

Token and capital reporting: canonical Roadmap and capital policy, ACE transparency snapshot, and the official mint. The supply and authority observation in Section 5 was independently checked against finalized Solana mainnet mint data on October 2, 2026.

Developer references: documentation, Nexior, X402Client, and FacilitatorX402.

Revision History

Version 1.2 — October 2, 2026: replaces the six-tier description with nine holder tiers; documents the active referral commission bonus, percentage-point calculation, per-beneficiary cap and settlement conditions; distinguishes release-specific early access from general promises; clarifies supported Credits billing and x402 exclusions; refreshes dated token observations; retains the 3% qualifying-receipt capital policy; and adds sources and risk disclosures.

Version 1.1 — October 1, 2026: payment-linked capital policy and transparency reporting.

Version 1.0 — August 2026: initial publication.

Material changes to holder tiers, benefits, payment rails or capital policy require a corresponding whitepaper review. Routine catalog changes belong in live service documentation. Approved changes retain a visible version, update date and revision summary at this permanent URL.