Nexar Network Whitepaper

Nexar Network is an on-chain payment, commerce, and business infrastructure project built around the NXR token and the ATLAS Business Operating System. The network operates on BNB Smart Chain (BEP20), with a long-term path toward sovereign payment infrastructure.

The public platform is not a collection of disconnected products. One identity signs in through Auth.js, one ATLAS profile participates in the professional network, the same identity can sell through Merchant / Business Hub and buy through Marketplace, and financial rails (wallet, checkout, invoices, settlement, payouts) settle value for that same account.

This document describes the architecture as it exists in the Nexar Network repository: 36 ecosystem modules across 5 categories, canonical token and contract configuration, marketplace commerce, ATLAS social and business surfaces, and planned infrastructure that is not yet a public product.

Payments. Commerce. Business. AI. One connected Web3 ecosystem. The objective is practical financial and business infrastructure — not a speculative landing page.

Nexar is building a connected Web3 ecosystem for payments, commerce, business, and AI — powered by ATLAS on BNB Smart Chain. The product surface is organized as a single ecosystem:

• Nexar Network — the company and public protocol brand, website, token, and on-chain contracts.
• ATLAS — the Business Operating System: identity, professional network, messaging, media, business, and AI assist.
• Marketplace — the commerce layer: discovery, cart, checkout, storefronts, and merchant operations.
• Financial infrastructure — wallet, payments, invoices, settlement, treasury, and payouts.
• On-chain infrastructure — NXR on BNB Smart Chain (Chain ID 56).
• Future infrastructure — Explorer, Bridge, Nexar Chain, and a public developer platform, documented as planned.

Canonical module count is derived from the ecosystem registry: 36 modules. The homepage orbit and this Whitepaper read the same list.

The vision is to establish Nexar Network as payment and business infrastructure for a decentralized economy: businesses, developers, and individuals transferring value globally without unnecessary cost, delay, or fragmented identity.

Beyond operating as a digital asset, NXR is intended to become the utility layer of that infrastructure — used for commerce, fees, payouts, and, when Nexar Chain exists, network gas. ATLAS remains the operating system on top of those rails.

The mission is to simplify blockchain payments and business operations by combining security, scalability, transparency, and low transaction costs in one account.

• High performance settlement on supported EVM networks
• Security and authorization that stay server-authoritative
• Transparent tokenomics and published contracts
• Accessibility through ATLAS rather than a maze of separate logins
• Low, published platform fees with a distinct NXR advantage
• Developer-friendly infrastructure as a future public platform
• Long-term sustainability through vesting, treasury, and product fees

Mainstream blockchain adoption still collides with fragmented identity, difficult merchant integration, unpredictable fees, and products that treat social, commerce, and payments as unrelated applications. Businesses stay on expensive processors because integrating wallets, catalogs, settlement, and compliance as separate stacks is technically costly.

• Complex wallet onboarding disconnected from business identity
• High or opaque payment processor fees
• Slow or manual international settlement
• Fragmented chains and explorers
• Limited merchant tooling that is actually wired to settlement
• Social and commerce accounts that do not share a profile
• Poor beginner experience across wallets, checkouts, and dashboards

Nexar Network answers those problems with one identity, one operating system, and one commerce/payment stack on one live EVM network — expanding later into explorer, bridge, sovereign chain, and public APIs.

Planned items (Explorer, Bridge, Nexar Chain, public Developer APIs & SDK) are labeled planned in the registry. They are not presented as live products.

NXR is a BEP-20 (EVM-compatible) token deployed on a single active network, BNB Smart Chain, configured in lib/constants/networks.ts. That module is the single source of truth for chain ids, RPC endpoints, explorers and contract addresses across the whole platform.

BNB Smart Chain is the settlement rail for marketplace crypto checkout, merchant payouts, withdrawals, treasury operations and subscriptions. Concentrating on one chain keeps settlement auditable and lets the platform verify every payment against a single explorer.

NXR previously also had a deployment on a now-retired network. That deployment is inactive: it is no longer supported, is not used for settlement, and must not be used to send funds. Only the addresses in Official Contract Information below are current.

The token market surface is /market. Mint is disabled at the contract configuration used by the public site. NXR token (BNB Smart Chain): 0xc37c9eeAB826e5bcB4ed2b798123915Cd596c909. Related contracts — Nexar Treasury: 0xaCc4915C896Cd4E0d18C65fe5e10DcFBAe190f12; Team Vesting: 0x55D0402D6E81F598cdAdC3132Fe4982912FdB787. NXR is bought on the open market through the trading platforms listed on the homepage; there is no active token sale.

Team allocation is 75,000,000 NXR (15% of max supply). 25,000,000 NXR is the initially available team amount. The remaining 50,000,000 NXR is locked in the dedicated team vesting contract with a 12-month cliff and gradual unlock. The canonical vesting address is published with other official contracts in this document.

Vesting is a contract control, not a marketing promise. No hidden unlock schedule is described beyond the published allocation and the on-chain vesting contract.

• Marketplace and invoice payments where merchants enable crypto checkout
• Wallet transfers of NXR on supported networks
• Reduced Marketplace platform fee versus other supported crypto
• Business payouts with a lower NXR platform fee and a qualified first-year advantage
• Ecosystem services inside ATLAS (fees and commerce, not a second token login)
• Community rewards allocation as published in tokenomics
• Governance, staking, validator rewards, and Nexar Chain gas — future, not live products

ATLAS is the Business Operating System of Nexar Network. It is not a separate company product with a second account. The core rule is: one ATLAS identity, one account, one ecosystem.

Identity and authentication

Authentication is Auth.js (Auth.js v5) with a Supabase adapter. Session cookies are httpOnly. Role and profile data live in PostgreSQL. Shopping, selling, messaging, and business membership are capabilities of that identity — merchants and businesses can still buy as themselves. HQ / platform-owner roles are excluded from storefront shopping.

Profiles and professional network

Canonical social records are atlas_network_profiles. People and companies have public network profiles. Connections, companies, jobs, and events sit in the same graph. Completeness scoring for profiles is enforced in the database and surfaced in the ATLAS UI.

Feed, posts, comments, reactions, connections

The home feed at /atlas is the primary social surface. Posts support comments, reactions, and shares. New posts and comments can broadcast over ATLAS realtime channels so open clients update without a full reload. Connections are first-class network edges, not a separate CRM login.

Messaging, notifications, media

Direct messages and Connect workspaces share /atlas/messages. Notifications consolidate social and commerce events at /atlas/notifications. Images, video, and attachments go through the ATLAS media pipeline (upload, authorization, transcode, proxy) rather than public hotlinks.

Stories, video, reels, communities, search, AI

Stories are posts with metadata.kind = story and a 24-hour expiry job. Reels use metadata.kind = reel. Longer video lives at /atlas/videos. Communities are named groups with membership and posts. Search indexes people, companies, posts, jobs, and products. AI assist is available at /dashboard/ai and via the global assistant; it is still expanding, so the registry marks AI as building.

Business Hub, marketplace, payments

Business Hub is merchant/business operations for the same identity. Marketplace is the public commerce channel. Payments and wallet are capabilities, not a second registration. Analytics derive from domain events (orders, catalog, payouts) rather than a parallel warehouse product.

Canonical entry: /atlas.

Business Hub is the company aggregate inside ATLAS: store, catalog, orders, invoices, analytics, payouts, and settings. A business is attached to an ATLAS identity through membership. It is not a second user account.

• Merchant dashboard at /merchant
• Store Builder writes a storefront draft; publish makes it live
• Products, collections, inventory, and media owned by the business
• Orders and invoices shared with the customer portal as the same records
• Business payouts at /dashboard/finance/payouts

Store creation is free (0 USD). Full merchant dashboard access uses subscription plans: Monthly at $2 / 30 days, or Yearly at $20 / 365 days. Subscription revenue belongs to Nexar and is separate from Marketplace transaction fees and Business Payout platform fees.

Marketplace is the public sales channel of Nexar Network. Canonical routes live under /marketplace. It uses the same ATLAS identity. There is no marketplace-only login.

Discovery and storefronts

Shop search is /marketplace/shop. Product pages use product handles. Public storefronts render at /marketplace/store/[slug] from published store settings. Store Builder can preview a draft with ?preview=1 for the owner without publishing.

Catalog

Products support variants, media, inventory, categories, and collections (merchant collections and storefront collection sections). Pricing is server-authoritative: checkout does not trust client-displayed prices. Variant stock is decremented in the database.

Cart, wishlist, checkout

Cart and wishlist belong to the signed-in shopper profile. Checkout at /marketplace/checkout converts cart lines into orders and invoices. Shopper roles are customer, merchant, and business.

Payments and fees

Supported payment assets are NXR, BNB, USDT, and USDC on the networks configured by the platform. Official Marketplace platform fees are 0.35% for NXR and 0.5% for other supported crypto assets. Runtime settlement still uses fee_schedules / private.calculate_platform_fee.

Orders, invoices, reviews

Checkout creates orders per store and payable invoices. Customers pay invoices through server-verified crypto deposits. Product reviews exist and are moderated in HQ. Settlement splits platform fee to treasury and net to the merchant.

Financial infrastructure is the payment layer of Nexar: Wallet, Pay, Payments, Treasury, Settlement, and Payouts. Commerce checkout, invoices, and business disbursements all use this layer. Social ATLAS surfaces do not invent a second ledger.

• Wallet (live) — Self-custody wallet for NXR and multi-chain assets with seamless dApp connectivity.
• Pay (building) — Merchant payment gateway for accepting NXR and stablecoins with instant settlement.
• Payments (live) — Crypto payment processing on BNB Smart Chain, with auditable settlement and payout flows.
• Treasury (building) — Treasury operations, reserves, and multi-chain settlement controls.
• Settlement (live) — Automated settlement engine for merchants, marketplaces, and business payouts.
• Payouts (live) — Business payout platform with multi-asset support and NXR fee advantages.

The Nexar ecosystem is a directed stack, not a grid of unrelated cards:

Nexar Network → ATLAS → financial infrastructure → social/business infrastructure → commerce → on-chain infrastructure → future infrastructure

Integration rules: one Auth.js session; domain tables as source of truth; marketplace presentation of merchant masters; payments verified server-side; planned modules not advertised as live. The catalog that follows documents every module in the canonical registry.

The professional network is an ATLAS domain (atlas-network), not a white-label social clone with a separate user table. Profiles, companies, connections, feed posts, comments, and reactions share the signed-in profile id.

Public network routes include /atlas/network and profile URLs under ATLAS. Company pages are the public face of Business Hub entities. Privacy filters and completeness rules run in the service layer and database triggers.

Commerce does not replace the graph: a merchant remains a person/company on the network who also operates a store. Messaging and notifications attach to the same profile.

Messaging is an ATLAS capability. Direct conversations and Connect workspaces are reached from /atlas/messages. Messages belong to the network profile of the signed-in identity. There is no anonymous marketplace chat login.

Realtime behavior uses Supabase Realtime broadcast channels, because ATLAS authenticates with Auth.js rather than Supabase Auth. The server relays events (new message, read receipt, reactions, unread counts) on unguessable conversation/user channel names. If a client is offline, it refetches on open — broadcasts are best-effort, not a second durable store.

Attachments and video messages go through the ATLAS media proxy with authorization checks. Permissions follow conversation membership. Professional networking uses the same composer; commerce does not fork a second messenger.

The notification hub at /atlas/notifications is the unified in-app inbox. Portal-specific shims redirect here so merchants and customers do not maintain a second bell. Events carry metadata links back into feed, orders, or messages.

Unread state is stored durably. Live updates can ride the same realtime user channel used by messaging. Commerce order events and social events share this hub rather than parallel notification products.

Stories are ephemeral ATLAS posts: atlas_network_posts with metadata.kind = story. They appear on the feed story rail and as a profile indicator. Expiry is handled by a scheduled job that targets the post metadata kind (not a separate media-kind table).

Stories use the same identity and media pipeline as the feed. They are not a second creator product. View counts can broadcast on a story channel for live clients.

Longer-form video posts use the ATLAS post/media pipeline. The videos browser is /atlas/videos. Playback is authorized through ATLAS media rather than unprotected object URLs. Video is a network content type, not a disconnected streaming app.

Reels are short-form vertical video posts with metadata.kind = reel, distinct from Stories. Discovery and playback live at /atlas/reels and /atlas/reels/[id]. Reels share identity, comments, and media authorization with the rest of ATLAS.

Communities are named groups with membership and community-scoped posts. Routes: /atlas/communities and /atlas/communities/[slug]. Authorization tests cover membership. Communities sit inside the ATLAS network — they are not a second forum product or a marketplace replacement.

ATLAS search at /atlas/search is the social and professional index (people, companies, posts, jobs). Product discovery also exists on /marketplace/shop. Ranking logic lives in the ATLAS search services. Search does not mint a second identity; results deep-link into profiles, posts, or products.

Nexar AI is an assistive workspace capability, not a separate login. The dashboard assistant is /dashboard/ai. A global Nexar assistant can ground answers in site knowledge (navigation, tokenomics, marketplace FAQ). Commerce surfaces can invoke assistive copy where wired.

The module is marked building: the assistant exists and is expanding. This document does not claim a fully autonomous operations AI.

Merchant analytics at /merchant/analytics cover catalog and order activity for the business that owns the store. Platform analytics for treasury and HQ exist as operational surfaces. Analytics read domain tables; they are not a second source of truth for prices or balances. Broader BI is still expanding (registry: building).

Commerce is a layer on ATLAS identity. Merchant masters (store, product, variant, inventory, collection) are written in merchant/business modules. Marketplace is the public presentation and checkout. Customer portal is the buyer view of the same orders and invoices.

Money movement: cart → server checkout → order + invoice → payment session (crypto or card) → verification → settlement (platform fee to treasury, net to merchant) → optional business payout. Client UI never authorizes a price.

Merchant is a role/capability on the ATLAS profile. Onboarding can open from Marketplace seller flows. The merchant dashboard is /merchant: catalog, orders, store builder, billing, wallet, analytics. Admin review may apply before marketplace listing. Merchants remain shoppers under SHOPPER_ROLES.

Customer operations live at /customer (orders, invoices, addresses, purchases). Shopping is not limited to the customer role: merchants and businesses can buy as themselves. Cart, checkout, and wishlist require requireShopper(). There is no second customer password.

Product masters include title, handle, description, media, categories, inventory, and variants. Variant pricing uses COALESCE(variant, product) on the server. Invalid or inactive variants are rejected. Product pages are /marketplace/products/[handle]. Media is stored through the platform media pipeline.

A store belongs to a business owned by an ATLAS identity. Public storefronts use published keys in store_settings.marketplace_profile. Drafts live under a _draft key until publish. Storefront sections include featured, collections, and products. Store Builder is /merchant/store/builder.

Orders are created by marketplace checkout (including create_marketplace_checkout paths) from cart lines. Lifecycle covers payment, fulfillment, and completion. Buyer view: /customer/orders. Seller view: /merchant/orders. The record is shared; the portals differ.

Checkout is server-authoritative. Inventory, coupons, taxes, and prices resolve in the database. The canonical UI is /marketplace/checkout. Guest checkout is not a second identity system: a signed-in ATLAS shopper is required. Totals, fees, and payment method are shown before confirmation.

Checkout creates payable invoices (typically per store). Merchants can also issue invoices. Pay Now starts a crypto payment session against the invoice. Hosted invoice pay lives under /pay/i/[token]. Customer list: /customer/invoices. Merchant list: /merchant/invoices.

Payments is the crypto processor behind marketplace and invoices. Crypto rails use the configured BNB Smart Chain assets. Amounts are bound server-side. Verification workers confirm on-chain deposits before marking invoices paid.

Marketplace platform fees: NXR 0.35%; other supported crypto assets 0.5%. These are distinct from payout platform fees and blockchain gas.

After payment verification, settlement splits value: platform fee to treasury, net to the merchant. Settlement workers and fee-split logic live in payments/settlement modules. Escrow and refund paths exist where implemented and are authorization-gated. Settlement is invisible on the social feed and required for commerce.

Business payouts disburse settled merchant funds. Entry: /dashboard/finance/payouts. Assets: NXR, USDT, USDC, BNB on BNB Smart Chain. Platform fees (distinct from marketplace fees):

• NXR = 0.10% (minimum $0.50)
• USDT = 0.15%
• USDC = 0.15%
• BNB = 0.20%

NXR First-Year Advantage is implemented in the payouts service: after qualification (including a minimum count of qualifying NXR payouts and qualifying volume), NXR platform fee can be 0% for one year, then returns to the standard NXR rate. Blockchain network cost may still apply when the Nexar platform fee is zero.

The wallet is the self-custody / connected-wallet surface for NXR and supported assets. Canonical entry /wallet dispatches to the role-aware finance wallet. Supported connectors in the public product include MetaMask, Rabby, Coinbase, and WalletConnect as listed on the roadmap and hero wallet logos. Wallet is an ATLAS capability of the signed-in identity.

Pay is the hosted collection surface for invoices and store payment links: /pay/i/[token] and /pay/s/[slug]. Crypto sessions on the configured payment networks are used. The broader merchant-facing Pay gateway product is still expanding, which is why the registry marks Pay as building and does not offer a marketing-only /pay CTA.

Treasury holds platform reserves, fee intake, and settlement controls. Ordinary users do not operate treasury. The published treasury address is listed with official contracts. Treasury administration is an internal surface; the module is marked building as public packaging continues.

BNB Smart Chain is the EVM settlement network (Chain ID 56). NXR token: 0xc37c9eeAB826e5bcB4ed2b798123915Cd596c909. Nexar Treasury: 0xaCc4915C896Cd4E0d18C65fe5e10DcFBAe190f12. Team Vesting: 0x55D0402D6E81F598cdAdC3132Fe4982912FdB787. Explorer: BscScan (https://bscscan.com). Marketplace crypto checkout, payouts, withdrawals and treasury operations all settle here.

NXR previously had a second deployment on BOT Chain Mainnet (Chain ID 677). That network has been withdrawn from Nexar: it is not a supported network, it is not used for settlement, and the platform will not verify, accept or transfer funds on it.

Historical records are preserved for audit, and anyone holding assets on that network should treat them as stranded and contact support. Current operations, settlement, payouts and treasury activity are entirely on BNB Smart Chain. Nothing in the active product may be configured to use the retired chain.

On-chain infrastructure is NXR on BNB Smart Chain, a unified wallet UX (building), and payment rails that feel like one checkout (building). Deploying to additional networks is possible and is scoped in the roadmap, but it will be announced before it ships: a network is only added to lib/constants/networks.ts when the platform can verify payments, settle and pay out on it. The planned Explorer, Bridge and Nexar Chain extend this layer and are listed separately as planned.

A Nexar-branded explorer is planned. Today, contract and transaction inspection uses BscScan. The explorer would observe network activity; it would not become a second identity system.

A Nexar-operated cross-chain bridge is planned. No Nexar bridge UI is in the current product. A future bridge would move assets betweenBNB Smart Chain and later networks — not accounts or ATLAS profiles.

Nexar Chain is the planned sovereign chain for payment infrastructure and a validator network. Current settlement is BNB Smart Chain. ATLAS would remain the operating system on top of those rails. This module is planned, not live.

A public developer platform (REST/GraphQL, webhooks, SDKs) is planned. Internal HTTP surfaces already exist for marketplace and commerce operations inside the application. The public /developers page is the documentation entry; it is not a claim that a full public SDK is shipping. Integrations must use ATLAS identity and existing domain contracts — not parallel objects.

ATLAS realtime uses Supabase Realtime broadcast channels scoped by feed, post, story, conversation, and user ids. The service-role key stays on the server. The browser anon client subscribes; it does not use Supabase Auth RLS postgres_changes, because login is Auth.js. Marketplace also defines realtime channel names for catalog, cart, and inventory coordination. Broadcasts are ephemeral; PostgreSQL remains durable truth.

Images, video, documents, story media, message attachments, and product media are stored through the platform media stack: validation, metadata stripping, transcode where required, and an authorized media proxy. Duration limits apply to video. Object access is not a public CDN free-for-all; authorization tests cover storage paths. Marketplace product media and ATLAS social media share this infrastructure.

• Verified Contract. Token and presale contracts verified on BscScan with source code publicly available for independent review.
• Transparent Allocation. Full tokenomics published with on-chain verifiable supply. Mint function permanently disabled.
• Secure Vesting. Team allocation locked with gradual vesting after one year. No hidden unlocks or surprise emissions.
• Community Trust. Founder-led development with public roadmap, open communication, and long-term ecosystem commitment.

Application authorization is role- and capability-based (customer, merchant, business, HQ roles). Checkout, settlement, refunds, media, and admin routes are server-gated. Rate limits apply to session and media paths. Platform Owner HQ adds password change and TOTP onboarding. No system is claimed to be risk-free.

Canonical authentication is Auth.js with hashed credentials in the Auth.js user store and application profiles in PostgreSQL. Redirects after login are capability-aware (ATLAS, merchant, customer, marketplace). There is one session cookie domain for the app. Wallet connection is a payment/web3 capability attached to that session, not a replacement login for social or commerce.

Durable data lives in PostgreSQL (Prisma schema and SQL migrations) hosted with Supabase. Domain tables include profiles, ATLAS network posts/media, conversations, stores, products, variants, carts, orders, invoices, payments, payouts, and fee schedules. Sensitive RPCs (platform fee calculation, settlement) run as server-side database functions. RLS policies exist for ecosystem/business context; application guards remain required because Auth.js is the identity provider.

Integration is compositional, not copy-paste. A new store still uses the same profile. A paid order still writes the same invoice table. A message still belongs to the same network user. Public website and Whitepaper both import ECOSYSTEM_MODULES so module names, categories, and statuses cannot drift independently.

Category counts today: Financial Infrastructure (6), ATLAS Operating System (12), Commerce (10), Multi-Chain Infrastructure (4), Future (4).

The public roadmap is the canonical ROADMAP data used on the homepage. Statuses are not rewritten here to look more complete.

These addresses come from lib/constants/networks.ts (BSC aliases also exported as CONTRACTS). They are not duplicated as a second constant table in this Whitepaper, so the document cannot drift from the addresses the platform actually uses.

Nexar Network was founded by Mahmoud Elgabry, Founder & CEO. Mahmoud Elgabry founded Nexar Network with a vision to create a connected Web3 ecosystem for payments, commerce, business, and AI. With deep expertise in blockchain architecture and financial technology, he leads the development of the NXR ecosystem from BNB Smart Chain to a purpose-built Nexar Chain.

We're not building another token with utility added afterward. We're building the products, infrastructure, and business ecosystem first — and designing NXR to provide real utility across Nexar.

Official founder LinkedIn: https://www.linkedin.com/in/mahmoud-elgabry-142644419

The following channels are the official public configuration from lib/constants/site.ts. Do not treat unofficial look-alike accounts as Nexar Network.

• Xhttps://x.com/NexarNetwork
• Telegramhttps://t.me/NexarNetworkCommunity
• Telegram Channelhttps://t.me/nexarnetworkofficial
• Instagramhttps://www.instagram.com/nexarnetwork1
• Facebookhttps://www.facebook.com/share/1EPeMgVPpa/
• Discordhttps://discord.gg/MVJVwKDgSh
• GitHubhttps://github.com/nexarnetwork1
• LinkedInhttps://linkedin.com/in/mahmoud-elgabry-142644419
• TikTokhttps://www.tiktok.com/@nexarnetwork?_r=1&_t=ZS-98DcjM8zOEv
• Binance Squarehttps://app.binance.com/uni-qr/cpro/nexarnetworkofficial?l=en&r=T29U688W&uc=app_square_share_link&us=copylink
• YouTubehttps://www.youtube.com/@nexarnetwork-k3n

Cryptocurrency and experimental financial software carry significant risk. NXR value can fluctuate. Nexar Network does not guarantee returns. Participants must do their own research and comply with local law.

Smart contracts may be verified and vesting may be locked; no system is entirely without risk, including key compromise, chain congestion, oracle/price errors, and integration bugs. Legal pages on the site (Privacy, Terms, Disclaimer) apply in addition to this document.

Nexar Network is one system: NXR on BNB Smart Chain, ATLAS as the operating layer, Marketplace as the commerce layer, financial rails as the payment layer, and a documented future layer for explorer, bridge, sovereign chain, and public APIs.

The public website, this Whitepaper, and the product routes share the same module registry, tokenomics, contracts, and official channels. That is the standard this document is written to preserve.

Read the live product at https://www.nexarnetwork.org, enter ATLAS at /atlas, and commerce at /marketplace.