NVEX Ecosystem
Zetaverse connects creators and brands
Zetaverse is a creator–brand platform run in Malaysia by a separate operator. Its business model is a Creator Operating System connecting readiness assessment, creator development, brand matching, campaign delivery and results records. NVEX is pursuing a BHCT integration partnership with Zetaverse.
- —
- —
- —
These figures describe Zetaverse’s platform operations and are counted separately from BHCT usage and reward activity.
People
Creators building their audience
Content
Content that stays consistent and authentic
Community
Real talk on challenges with fellow creators
Opportunities
First opportunities, brand deals and monetization
Ecosystem roles
An ecosystem connected through distinct roles
NVEX issues and manages the token, while a separate operator runs Zetaverse’s platform business. The parties are pursuing a BHCT integration partnership; scope and conditions will be published once confirmed.
NVEX · BHCT
Token issuance and management
The NVEX Foundation manages BHCT’s contract, supply, disclosed wallets and related disclosures, and designs integration options.
Zetaverse
A separately operated platform business
Zetaverse’s operator handles creator development, matching, campaigns and business operations. Its operator is distinct from NVEX.
Brands · Creators · Fans
Ecosystem participation
Brands propose campaigns, and creators explore opportunities that fit their readiness. Fan participation and token use follow separately published features and conditions.
A five-step campaign operating model
Zetaverse’s proposed process for preparing and matching creators to brand needs. These steps describe the business model; the operating status of BHCT features is shown separately.
01 · Train
Training
Creators define their niche, audience and strengths, while the operator supports content skills and readiness to respond to briefs. The output is a readiness profile recording direction and areas to improve.
02 · Filter
Screening
The operator reviews campaign fit, response and delivery history, and evidence of brand safety. The model records the review in a shortlist and readiness record.
03 · Package
Packaging
Creators and the operator organize profiles, content samples, production scope, pricing and rights terms. They prepare proposal materials that brands can compare and discuss.
04 · Deploy
Deployment
Brands and creators agree on deliverables, schedules, revision scope and usage terms, while the operator coordinates matching through delivery and approval. The output is a campaign record connecting contractual terms with approval history.
05 · Report
Reporting
The operator gathers evidence of posting, revisions and approval, together with performance metrics agreed in advance. The model produces campaign reports and creator records to inform future matching and repeat briefs.
Zetaverse’s operating model: the creator journey
01
Creatopia
An online creator event to learn, connect, create and grow
02
Zetaverse
A stage for joining the creator ecosystem
03
14-day campaign ready
A 14-day program for preparing for brand campaigns
04
Community
A process for connecting with fellow creators
05
Opportunities
A stage for exploring brand collaborations that fit readiness
An operating model from event participation to campaign preparation and opportunity discovery. Check separate announcements for each program’s recruitment and operating status.
Six criteria for assessing creator readiness
Proposed assessment criteria developing the operating model in Zetaverse’s source material. The operator will announce actual selection criteria and required materials for each program.
Positioning
Review whether niche, audience, platform and region fit the brand brief. The criterion is whether creators can explain the content value they offer to a particular customer and market.
Samples · profile
Review presentation, production quality and campaign fit through profiles, portfolios and content samples. The proposed approach uses work brands can inspect, alongside creators’ own descriptions.
Response · deadlines
Record responses, schedule confirmation, revision handling and whether agreed deadlines were met. Assess reliability by distinguishing willingness to participate from actual delivery history.
Brand safety
Review content, advertising disclosures and potential conflicts with brand guidelines before selection. The proposed approach records campaign-specific restrictions, cautions and review findings.
Content rights
Check rights holders, permitted channels, territories and duration, and advertising and reuse scope. The direction is to distinguish production compensation from content usage terms in contracts and approval records.
Reporting
Check whether posting URLs and times, agreed platform metrics, and revision and approval evidence can be supplied. Record sources and measurement periods so results can be compared in future campaigns.
Zetaverse’s business model and expansion direction
Business areas connecting brand demand with creator capabilities. Business revenue and BHCT use or reward policies are governed by their respective contracts and conditions.
Custom brand campaigns
A monetization model tailoring UGC, influencer and branded content to a brand’s goals, deliverables, region, duration and usage rights, with compensation for production and operations defined by contract. Actual scope and prices are negotiated per campaign.
Commerce · market entry
A path considering contractual compensation for sales contributions through affiliate and live commerce, alongside fees for localization, creator sourcing and campaign operations. Sales-linked terms and market-entry support scope are negotiated separately.
Selected IP · fan business
A long-term direction monetizing content production, product sales, licensing, memberships and fan experiences around creators with proven commercial results. Rights and business participation are set by individual contracts; BHCT integration and holder rights are reviewed separately.
Actual service scope and commercial terms must be checked in the operator’s specific announcements and contracts. Long-term plans or holding BHCT alone do not grant Zetaverse equity, dividends, IPO participation or IP ownership.
A proposed flow connecting campaigns and BHCT
A future operating flow assessing token integration after brand demand, review and recordkeeping. It does not mean every step is currently connected and operating.
- 1
Brand brief · budget
The brand proposes its target market, deliverables, schedule, usage scope and budget, then discusses campaign terms. The model distinguishes the contractual business transaction from any decision to apply the token.
- 2
Operator review · records
Zetaverse’s operator checks deliverables against agreed conditions and records approvals, revisions and performance evidence. The design treats campaign acceptance and on-chain payout confirmation as separate records.
- 3
BHCT reward integration under prior conditions
An integration design for deciding whether BHCT rewards apply under eligibility, review requirements and payout conditions agreed and announced in advance. Funding sources, payout responsibility, amounts and settlement rules will be announced separately once policy is confirmed.
- 4
Assessing service · fan experience use
A stage assessing BHCT use for services, memberships and fan experiences. Providers, eligibility, charges and access scope are defined by feature-specific conditions; holding the token alone does not create IP ownership.
Actual integration is subject to agreement and operational and regulatory review. Reward budgets, payers, amounts, settlement rules and service conditions will be published once confirmed; this flow is not a promise to distribute business revenue as returns to token holders.
Proposed operating model
An operating proposal connecting campaigns and BHCT
BHCT is proposed to connect a common usage unit across participants, personal wallet holdings, fixed supply, public payout records and service reuse. A separate operator runs Zetaverse’s business; NVEX issues and manages BHCT and is pursuing an integration partnership, with actual benefits to be tested in campaign and optional-service pilots.
This operating proposal is for discussion and validation; it does not establish that an agreement has been signed or a product launched. Confirmed partnership scope, products, budgets, responsibilities and terms will be announced through disclosures.
Separate contractual compensation from optional token rewards
The business model starts with actual paid brand demand and runs through campaign delivery and acceptance.
A paid brand brief
The brand proposes objectives, deliverables, timing and budget, then negotiates compensation and business contract terms.
Zetaverse operations and acceptance
The separate operator coordinates training, assessment, packaging, matching and delivery review, recording results and approvals.
Contractual pay + optional BHCT rewards
Creator compensation follows the agreed contract. Additional BHCT rewards require separate eligibility, limits and consent; they do not automatically replace contractual pay.
Under this proposal, general campaign participation, basic assessment and matching do not require BHCT holdings. Holding or using BHCT does not guarantee matching priority, quality scores or revenue sharing; the design gives no selection or quality-score advantage based on token holdings or usage. Selection and acceptance are assessed separately through brief fit, readiness and delivery evidence.
Start with specific support services as product candidates
These are representative optional support products, separate from basic readiness assessment and campaign matching. Check the pilot operating tables on the token page for product prices, capacity, status and applicable periods. Actual use begins only after supply agreements, cash costs and slots are secured and launch is announced.
Profile · portfolio feedback clinic
- Proposed scope
- Additional support reviewing the creator’s submitted introduction, portfolio and samples, with feedback on presentation and structure.
- Proposed output
- Defined feedback and an improvement checklist. This is not a product for purchasing basic selection assessment or matching scores.
Editing · subtitles · localization support
- Proposed scope
- Support providing editing, subtitles or localization for a predefined source length, language and format.
- Proposed output
- Agreed deliverables and revision records. Scope, revision limits and deadlines must be defined for each product in advance.
Catalogue terms to publish before each product launches
- Scope and provider
- Identify the provider, work, required inputs, outputs, inclusions and exclusions for each product.
- Capacity and quantity
- A catalogue total close to the distribution budget does not guarantee availability of any particular product. Check demand concentration, such as clinic demand after training, and existing bookings; accept orders only within secured slots.
- Booking · delivery deadlines
- Set application and input deadlines, work start and completion dates, and the service period.
- BHCT amount
- Check product amounts, included work and additional-work conditions together with proposed or confirmed status and effective dates in the operating tables. Figure confirmation is separate from launch; accepted orders retain the terms agreed at the time.
- Wallets and reconciliation
- The default proposal takes payment directly into NVEX’s published ecosystem receiving wallet and links order, transaction and fulfillment records. Service partners receive the agreed cash compensation for slots secured in advance.
- Cancellation · refunds
- Define cancellation windows, fulfillment criteria, refund responsibility, amounts, deadlines and dispute handling.
Memberships and fan access remain areas for Stage 2 review. Service use or token ownership alone does not create IP ownership, dividends, company equity or IPO participation rights.
Manage BHCT quantities separately from cash costs
Token receipts and reallocation records are separate from the cash needed to deliver actual services.
Proposed BHCT flow
- A finite reward pool
- Rewards after acceptance
- Voluntary service use
- Direct payment to NVEX’s ecosystem receiving wallet
- Proposed 100% reallocation of finalized receipts
Cash funding to secure separately
- Actual brand payments receivedCreator contractual pay · production and operating costs
- Actually secured · approved service cash budgetPartner service slots · actual delivery costs
Conditions for receipts, reallocation and settlement
- A finite reward pool
- Set quarterly budgets, an annual total reward payout cap and public wallets within the existing issued supply. Reallocated tokens paid again as rewards also count toward the annual cap under the proposal.
- Rewards after acceptance
- Approve payout eligibility and amounts separately from campaign acceptance, then verify transactions.
- Voluntary service use
- Recipients choose whether to hold tokens or use a launched service.
- Direct payment to NVEX’s ecosystem receiving wallet
- Receive service BHCT in the foundation’s official ecosystem wallet and link order and fulfillment records. Under the default proposal, service partners receive cash secured in advance rather than tokens.
- Proposed 100% reallocation of finalized receipts
- Reallocate 100% only after service fulfillment and the end of refund and dispute periods, subject to monthly reconciliation and approval. Exclude quantities still reserved and outstanding service obligations first.
- Actual brand payments received
- Record actual cash receipts and spending under brand business contracts. Token payouts do not themselves fund contractual compensation or costs.
- Actually secured · approved service cash budget
- Use cash actually secured from sources such as foundation budgets or budgets agreed with the operator for service slots, partner compensation and cancellation or refund contingencies. Token capacity totals do not establish that cash costs are funded.
- Proposed 100% reallocation of finalized receipts
- The Stage 1 default reallocates all receipts confirmed after fulfillment and the end of refund and dispute periods. Retain refund reserves, disputes and outstanding service obligations, and transfer only after monthly reconciliation and approval.
- Direct operator receipts require an exception agreement
- Any direct receipt by an operator or partner follows a separate contract’s return conditions. Count only finalized quantities actually returned and received; do not treat expected returns as available rewards in advance.
- Separate from automated escrow · forced recovery
- Service payments, returns and reallocation are designed around voluntary transfers, approval and reconciliation. They are not automated escrow or forced collection from holders through admin recover powers; check existing contract permissions and risks in their separate disclosures.
- Burning and circulation classification are separate
- Stage 1 proposes no burning or new issuance through reallocation. The design registers ecosystem receiving and reward-pool wallets as public excluded wallets; actual circulating supply follows currently registered wallets and supply-API calculation rules.
Token circulation is not proof of cash profit or new external demand. Brand revenue growth does not automatically trigger market purchases; reward-pool sustainability and cash costs must each be validated.
Why BHCT? Validate the expected benefits
Check whether BHCT improves actual use and settlement rather than assuming the features are unique to this token.
A common unit across support services
Test whether rewards can be used as a common unit across launched, agreed products. Benefits require actual service supply and terms.
Payout · usage reconciliation for both parties
Test whether NVEX and the operator can verify the same payout and usage records by linking campaign approvals, reward transactions, service orders and fulfillment.
Wallet holdings and service terms are separate
Assess recipients’ choice to hold or use tokens through their own wallets. The proposal puts no time-based expiry on BHCT itself; existing admin freeze, lock and recovery powers and future service, booking and access-right usage or expiry conditions can still apply separately.
Cash, points and stablecoins are alternatives to compare. The pilot must test actual service use, repeat use and total costs including fees, operations and refunds; it should not assume BHCT is uniquely necessary.
Meet the starting conditions, then validate through a pilot
These are pre-launch requirements, not completed milestones. Product sales or ongoing rewards are not assumed before partnership, supply, cash costs and user protections are agreed.
Pre-launch checklist
- Partnership scope and responsibility
- Agree on contracting parties, business, token and service roles, and responsibility for costs, delivery and disclosures.
- An actual service catalogue
- Confirm each product’s provider, scope, capacity, deadlines, BHCT amount, wallets and cancellation terms.
- Cash costs · refund contingencies
- Actually secure product quotations, service slots, staffing and production costs, and cancellation or non-delivery funding. Check product-level demand concentration, such as training participants versus clinic capacity, as well as aggregate balance.
- Limited rewards · public wallets
- Define reward eligibility, limits, public wallets and payout approval rules. Review new spending only after accounting for previously unused rewards, approved payouts and bookings, and reprocessing, refund and dispute reserves.
- Disputes · termination
- Agree on acceptance disputes, non-delivery, refunds, unpaid rewards and outstanding service obligations if the partnership ends.
- Pilot and monthly reconciliation
- Validate within a limited scope, then reconcile payouts, receipts, refunds, reallocation, balances and service costs each month.
Proposed metrics to publish after the pilot
- Actual usage relative to payouts
- Define recipients and an observation period to compare service usage with reward payouts. First define how to distinguish spending of existing holdings and repeated use of the same quantities.
- Actual users and repeat use
- Check users whose services were fulfilled and repeat-user counts and rates. Distinguish wallets, orders and actual users.
- Monthly quantity reconciliation
- Reconcile opening balances, payouts, foundation ecosystem receipts, refunds and reserves, finalized reallocations and closing balances. Count exception-contract operator returns only when actually received, and never count reallocation as new demand or revenue.
- Cash service costs
- Compare delivery counts, actual staffing and production costs, approved budgets and cancellation or refund contingencies by product. Do not combine token quantities and cash profit or loss into one metric.
Update public information once contracts, catalogues, budgets and pilot results are confirmed. Check the BHCT touchpoints below and dynamic whitepaper information for actual feature progress.
Where BHCT integration is being considered
Campaign payments, creator rewards, service use and fan participation are being assessed for integration, subject to agreement and operational and regulatory review.
Creator rewards
Rewards for campaigns with confirmed results
Service use
Proposed partner services such as profile clinics and production support
Campaign payments
How brands pay for campaigns
Memberships · Fan access
Creator IP, memberships and fan access
The statuses and progress below reflect the current public information for each use. Zetaverse’s business operations do not mean every BHCT feature has launched; eligibility, payout criteria and timing must be checked in separate announcements.
Explore BHCT features and conditionsProposed measures for validating results
Items and counting methods for validating the business. These are measurement designs; actual figures will be published with scope, periods and sources after operating records are available.
- Readiness · delivery completion
- Separate the share of program participants completing readiness requirements from the share of scheduled deliveries receiving approval in the relevant period. Distinguish participation, readiness, delivery and approval, recording completion criteria and deadlines.
- Campaign performance
- Measure views, reach and engagement, or orders and conversions verified through links or codes, according to the objectives agreed in the brief. Check original platform data, measurement periods and rules for handling duplicates.
- Operating economics
- Distinguish contracted campaign revenue from direct creator, production and operating costs, and record sourcing, onboarding and operational effort. Use these records to assess whether costs and returns improve with repeat delivery.
- Repeat briefs
- Count the brands that place another paid brief within a defined observation period after completing a campaign, and their share of completed-campaign brands. Distinguish inquiries, proposals in progress and paid repeat contracts when assessing recurring demand.
Consider IP business around proven creators and regional expansion after validating repeatable readiness and delivery, actual campaign performance, operating economics and paid repeat briefs. BHCT adoption and conditions are decided separately from business expansion, subject to agreement and operational and regulatory review.
Comparable business models and design references
Business operations, token use and service-exit references are distinguished below. These are independent services, not NVEX or Zetaverse partners or investments, and do not imply identical operating structures.
AnyMind · AnyTag / AnyCreator
Business operations reference: platforms connecting brand-side creator selection, content review and reporting with creator participation. Not classified here as a native-token example.
Zetaverse aims to connect brand briefs, creator readiness materials and delivery records in one operating workflow.
Partipost
Business operations reference: a platform bringing briefs, creator selection, post review, approval and performance tracking together. Not classified here as a native-token example.
Zetaverse’s proposed workflow focuses on agreeing deliverables, revisions, approval, publication, usage rights and settlement before a campaign starts.
Gushcloud
Business operations reference: a model spanning creator management and brand deals through production, IP development and commerce. Not classified here as a native-token example.
Zetaverse plans to consider production, IP and fan businesses for proven creators, expanding with appropriate contracts and rights processes.
Brave · BAT
Token-use reference: Brave Rewards connects advertising participation with BAT rewards and contributions to registered creators. Its transparency page also publishes usage metrics and BAT purchase records.
BHCT’s proposed model separates payouts, use, receipts, reallocation and service costs for verification and disclosure. This does not imply the same operator relationships or token-sourcing model as Brave.
Contentos · COS.TV
Historical token-design and service-exit reference: content activity was linked with COS rewards. An official notice schedules the COS.TV and Channel VIP wind-down from December 1, 2026, with full shutdown on December 14.
Not presented as evidence of sustained success. It informs the need to define responsibilities for unpaid rewards, bookings and refunds if BHCT integration ends. The notice says Contentos Mainnet, COS Swap and its mainnet wallet will continue.