NOX Tokenomics

NOX is an ERC-20 token on Ethereum mainnet with a fixed maximum supply of 800 million tokens. The token implements a deflationary mechanism through transaction taxes with automatic burning. A 2% tax applies to both buy and sell transactions, with a portion permanently burned on each trade.

The fixed supply creates scarcity that compounds with burn mechanics. 10% of all collected transaction fees burn permanently, reducing total supply over time. Additional burns occur through protocol fee operations. The burn mechanism creates persistent deflation that accelerates as trading volume increases.

Supply Distribution

NOX launched as a fair launch token from day one with no presale, no private rounds, and no VC allocations. The majority of supply entered circulation through public trading, ensuring equitable access for all participants. Reserved allocations support long-term ecosystem sustainability.

The TBD Reserve supports further ecosystem growth during development phases. These tokens unlock progressively based on milestone achievements and community governance decisions. No hidden allocations exist beyond those listed above.

Token Utility

NOX derives value from genuine utility across multiple protocols rather than pure speculation. Each use case creates organic demand that persists regardless of market sentiment.

Transaction Tax Structure

NOX implements a 2% tax on both buy and sell transactions. Transfer between wallets incurs no tax. The collected fees distribute automatically through the smart contract to support ecosystem sustainability.

Fee Distribution

Collected transaction fees distribute automatically across four destinations, ensuring sustainable ecosystem growth while maintaining deflationary pressure.

Deflationary Mechanics

NOX supply decreases over time through systematic burns. 10% of all transaction fees burn permanently, removing tokens from circulation forever. This creates persistent deflation that compounds as trading activity increases.

Additional trading limits protect against manipulation: maximum buy/sell capped at 0.5% of supply per transaction, maximum wallet holding at 4% of supply, and a 20-second cooldown between sells. These parameters ensure orderly markets while allowing organic price discovery.

The burn mechanism creates asymmetric outcomes. In bear markets, reduced activity means slower burns but also less sell pressure. In bull markets, increased activity accelerates burns while organic demand absorbs supply. Both scenarios trend toward reduced circulating supply over time.

Token launches today suffer from structural deficiencies that benefit insiders at the expense of genuine participants. Presales create information asymmetry. Whitelists concentrate early access among connected parties. Stealth launches favor bot operators with faster execution. The fundamental problem is that launch mechanisms were designed for issuers, not communities.

Fair launch rhetoric masks unfair realities. Teams retain allocations. Advisors receive tokens at zero cost. Early investors get preferential pricing unavailable to retail participants. By the time public trading begins, the price discovery period has already occurred privately. Public participants buy tokens that insiders acquired at fractions of the listing price.

The Bonding Curve Solution

Bonding curves eliminate information asymmetry by making the pricing function public and deterministic. The price at any moment depends solely on the current supply. There are no hidden allocations, no preferential access, no timing advantages. Everyone faces the same curve.

When a token launches through a bonding curve, the first buyer and the hundredth buyer interact with identical mechanics. Price increases monotonically with supply. Early participants pay less because fewer tokens exist, not because they received special access. This is fair by construction, not by promise.

The curve also provides continuous liquidity. Traditional launches create liquidity discontinuities: the presale period, the launch moment, the DEX listing. Each transition creates arbitrage opportunities and execution advantages. A bonding curve provides uninterrupted trading from first mint to graduation, eliminating these structural inefficiencies.

Privacy as a Feature

Anonymous launches serve legitimate purposes beyond regulatory arbitrage. Creators may wish to evaluate market reception without personal exposure. Teams building experimental protocols may prefer pseudonymous development during early stages. The association between identity and token can create legal ambiguity in jurisdictions with unclear regulatory frameworks.

NOX Launchpad requires only a wallet connection. No registration, no email, no identity verification. The protocol cannot collect information it never requests. Creator privacy is guaranteed by architecture, not policy. This privacy extends to participants: trading history remains on-chain but unlinkable to off-chain identity.

The protocol comprises three core contracts: the Factory, the Token implementation, and the Treasury. The Factory deploys new tokens using a minimal proxy pattern for gas efficiency. Each Token manages its own bonding curve and tracks progression toward graduation. The Treasury aggregates fees and executes the NOX buyback and LP provisioning logic.

Factory Contract

The Factory serves as the entry point for token creation. It maintains a registry of all deployed tokens and enforces creation fee collection. Using the EIP-1167 minimal proxy pattern, each token deployment costs approximately 100,000 gas rather than the 2,000,000+ gas required for full contract deployment.

Creation parameters include token name, symbol, and metadata URI. The Factory validates parameter constraints, collects the creation fee in NOX tokens, and deploys a new proxy pointing to the canonical Token implementation. The implementation address is immutable after Factory deployment, preventing upgrade attacks.

LaunchpadFactory.sol

function createToken(
    string calldata name,
    string calldata symbol,
    string calldata metadataURI
) external returns (address token) {
    // Collect creation fee (waived for NFT holders)
    if (!isNFTHolder(msg.sender)) {
        require(
            noxToken.transferFrom(msg.sender, address(treasury), CREATION_FEE),
            "Fee transfer failed"
        );
    }

    // Deploy minimal proxy
    token = Clones.clone(tokenImplementation);

    // Initialize token state
    IBondingToken(token).initialize(
        name,
        symbol,
        metadataURI,
        msg.sender
    );

    // Register in factory
    tokens.push(token);
    isToken[token] = true;

    emit TokenCreated(token, msg.sender, name, symbol);
}

Token Contract

Each Token contract manages its bonding curve independently. The contract holds ETH reserves collected from purchases and releases them on sales. The price calculation follows the quadratic bonding curve formula, ensuring smooth price discovery as supply changes.

Tokens exist in one of two states: bonding or graduated. In the bonding state, trading occurs through the curve. Upon reaching the graduation threshold, the token transitions to graduated state, curve trading halts, and liquidity migrates to Uniswap V3.

Treasury Contract

The Treasury aggregates fees from all protocol activity. It executes periodic conversions of collected ETH to NOX through Uniswap, then allocates the NOX according to protocol parameters: a portion burned permanently, a portion paired with ETH and added to liquidity, and a portion distributed to stakers.

The protocol employs a quadratic bonding curve where price increases proportionally to the square of the current supply. This curve shape provides gentle initial pricing that accelerates as supply grows, rewarding early participants while maintaining accessibility.

Price Function

Given current supply S, the instantaneous price P is:

Where k is the curve coefficient determining price sensitivity. The protocol uses k = 10⁻¹⁵, calibrated so that graduation occurs at approximately 800 million tokens with a $69,420 market cap.

Purchase Cost Calculation

Buying tokens requires integrating the price function over the purchase quantity. For a purchase of quantity Q starting from supply S:

This integral gives the exact ETH required to mint Q tokens. The contract computes this on-chain using integer arithmetic with appropriate scaling to prevent overflow.

Sale Return Calculation

Selling tokens follows the inverse process. For selling quantity Q from supply S:

The seller receives this ETH amount minus the protocol fee. Because purchase and sale use the same curve, there is no spread beyond the explicit fee. The protocol guarantees liquidity at the curve price for any trade size up to the current supply.

Curve Visualization

Numerical Example

At graduation, the contract holds approximately 23 ETH in reserves from cumulative purchases along the curve. This reserve forms the initial liquidity for the Uniswap pool.

When a token's market capitalization reaches $69,420, the graduation process initiates automatically. The contract locks all trading on the bonding curve and begins the migration sequence.

BondingToken.sol:graduate()

function graduate() internal {
    require(state == State.Bonding, "Not in bonding state");
    require(getMarketCap() >= GRADUATION_THRESHOLD, "Below threshold");

    state = State.Graduating;

    // Calculate liquidity amounts
    uint256 ethLiquidity = address(this).balance;
    uint256 tokenLiquidity = _calculateGraduationTokens();

    // Mint graduation tokens
    _mint(address(this), tokenLiquidity);

    // Mint fee to treasury (0.5% of supply)
    uint256 graduationFee = totalSupply() * 50 / 10000;
    _mint(treasury, graduationFee);

    // Create Uniswap V3 pool
    address pool = _createUniswapPool(ethLiquidity, tokenLiquidity);

    // Lock liquidity (1 year minimum)
    _lockLiquidity(pool, 365 days);

    state = State.Graduated;
    uniswapPool = pool;

    emit Graduated(pool, ethLiquidity, tokenLiquidity);
}

Graduated tokens deploy to Uniswap V3 with full-range liquidity. The protocol creates a new pool with 1% fee tier, deposits all accumulated ETH reserves paired with newly minted tokens, and locks the LP position for one year minimum. This prevents rug pulls where creators might remove liquidity after graduation.

The NOX ecosystem operates across two complementary blockchain networks: Ethereum mainnet for established DeFi integration and the Cellframe Network for quantum-resistant infrastructure. This dual-chain architecture provides users with deployment flexibility while maintaining unified liquidity through the bridge protocol.

Cellframe represents a strategic partnership that extends NOX capabilities into quantum-safe territory. As quantum computing advances threaten classical cryptographic systems, Cellframe's lattice-based cryptography provides long-term security guarantees. Tokens launched through NOX can exist natively on both chains, capturing users across both ecosystems.

Network Comparison

MultiChainFactory Architecture

The MultiChainFactory contract enables token deployment across deployment strategies. Creators select their preferred approach based on project requirements, target audience, and security priorities.

Deployment Strategies

Cellframe Partnership

The Cellframe Network integration represents a strategic alliance between privacy-focused ecosystems. Cellframe's unique technical capabilities complement NOX Launchpad's fair distribution mechanisms:

The bridge protocol enables bidirectional token transfers between Ethereum mainnet and Cellframe Network. Two implementations serve different needs: the general CellframeBridge handles any registered ERC-20 token, while the dedicated NOXBridge provides optimized parameters specifically for NOX token transfers.

Bridge security relies on a decentralized validator network. Validators observe transactions on both chains and submit cryptographic attestations. Transfers complete only when the required threshold of validator signatures accumulates, preventing single points of failure or compromise.

NOXBridge Specification

The dedicated NOX bridge provides specialized infrastructure for bridging the ecosystem's native token. Purpose-built parameters balance security, usability, and liquidity management.

Bridge Flow Diagram

Transfer Process: Ethereum → Cellframe

Users initiate outbound transfers by calling bridgeToCell() with amount and Cellframe recipient address. The contract validates parameters, deducts fees, locks tokens, and emits an event for validator monitoring.

NOXBridge.sol:bridgeToCell()

function bridgeToCell(
    uint256 amount,
    bytes32 cfRecipient
) external nonReentrant whenNotPaused returns (bytes32 txId) {
    // Validate bounds
    if (amount < MIN_BRIDGE_AMOUNT) revert BelowMinimum();
    if (amount > MAX_BRIDGE_AMOUNT) revert AboveMaximum();
    _checkDailyLimit(amount);

    // Calculate and collect fee
    uint256 fee = (amount * BRIDGE_FEE_BPS) / BPS_DENOMINATOR;
    uint256 netAmount = amount - fee;

    // Lock tokens in bridge
    IERC20 nox = IERC20(NOX_TOKEN);
    if (!nox.transferFrom(msg.sender, address(this), amount))
        revert TransferFailed();

    // Transfer fee to collector
    if (fee > 0) {
        if (!nox.transfer(feeCollector, fee)) revert TransferFailed();
        totalFeesCollected += fee;
    }

    // Generate transaction ID
    txId = keccak256(abi.encodePacked(
        msg.sender, cfRecipient, amount, block.timestamp, _txCount++
    ));

    // Record transaction
    transactions[txId] = BridgeTransaction({
        txId: txId,
        ethAddress: msg.sender,
        cfAddress: cfRecipient,
        amount: amount,
        fee: fee,
        netAmount: netAmount,
        timestamp: block.timestamp,
        confirmations: 0,
        direction: BridgeDirection.ETH_TO_CF,
        status: BridgeStatus.PENDING,
        cfTxHash: bytes32(0)
    });

    emit BridgeToCell(txId, msg.sender, cfRecipient, amount, fee);
}

Validator Confirmation

Validators observe bridge events and verify transactions on both chains. Each validator submits confirmation with the destination chain transaction hash. When three validators confirm, the transaction completes.

function confirmBridgeToCell(
    bytes32 txId,
    bytes32 cfTxHash
) external onlyRole(VALIDATOR_ROLE) {
    BridgeTransaction storage tx_ = transactions[txId];
    if (tx_.txId == bytes32(0)) revert TransactionNotFound();
    if (tx_.status != BridgeStatus.PENDING &&
        tx_.status != BridgeStatus.CONFIRMING) revert InvalidStatus();
    if (validatorConfirmations[txId][msg.sender]) revert AlreadyConfirmed();

    validatorConfirmations[txId][msg.sender] = true;
    tx_.confirmations++;
    tx_.status = BridgeStatus.CONFIRMING;

    emit BridgeConfirmed(txId, msg.sender, tx_.confirmations);

    if (tx_.confirmations >= MIN_CONFIRMATIONS) {
        tx_.status = BridgeStatus.COMPLETED;
        tx_.cfTxHash = cfTxHash;
        _removePending(txId);
        emit BridgeCompleted(txId, cfTxHash);
    }
}

Transfer Process: Cellframe → Ethereum

Inbound transfers reverse the flow. Users burn CF20_NOX on Cellframe, validators observe and sign attestations, and any party can submit signatures to the Ethereum contract to release locked NOX.

function bridgeFromCell(
    bytes32 cfTxHash,
    bytes32 cfSender,
    address ethRecipient,
    uint256 amount,
    bytes[] calldata signatures
) external nonReentrant whenNotPaused {
    if (ethRecipient == address(0)) revert ZeroAddress();
    if (amount == 0) revert ZeroAmount();

    bytes32 txId = keccak256(abi.encodePacked(
        cfTxHash, cfSender, ethRecipient, amount
    ));

    BridgeTransaction storage tx_ = transactions[txId];
    if (tx_.status == BridgeStatus.COMPLETED) revert AlreadyCompleted();

    // Create record if new
    if (tx_.txId == bytes32(0)) {
        tx_.txId = txId;
        tx_.ethAddress = ethRecipient;
        tx_.cfAddress = cfSender;
        tx_.amount = amount;
        tx_.netAmount = amount;
        tx_.timestamp = block.timestamp;
        tx_.direction = BridgeDirection.CF_TO_ETH;
        tx_.status = BridgeStatus.CONFIRMING;
        tx_.cfTxHash = cfTxHash;
    }

    // Process validator signatures
    for (uint256 i = 0; i < signatures.length; i++) {
        address signer = _recoverSigner(
            txId, cfTxHash, ethRecipient, amount, signatures[i]
        );
        if (!hasRole(VALIDATOR_ROLE, signer)) continue;
        if (validatorConfirmations[txId][signer]) continue;

        validatorConfirmations[txId][signer] = true;
        tx_.confirmations++;
        emit BridgeConfirmed(txId, signer, tx_.confirmations);
    }

    // Release if threshold met
    if (tx_.confirmations >= MIN_CONFIRMATIONS) {
        IERC20 nox = IERC20(NOX_TOKEN);
        if (nox.balanceOf(address(this)) < amount)
            revert InsufficientLiquidity();

        tx_.status = BridgeStatus.COMPLETED;
        _removePending(txId);

        if (!nox.transfer(ethRecipient, amount)) revert TransferFailed();

        totalBridgedToEth += amount;
        emit BridgeToEth(txId, cfSender, ethRecipient, amount);
        emit BridgeCompleted(txId, cfTxHash);
    }
}

Security Architecture

CellframeBridge: General Token Bridge

The general CellframeBridge handles any ERC-20 token registered by administrators. It operates similarly to the NOXBridge but with different fee parameters and without NOX-specific daily limits.

The NOX Launchpad generates revenue through three mechanisms: token creation fees, trading fees on bonding curve transactions, and graduation fees when tokens migrate to Uniswap. All fees ultimately flow into the NOX ecosystem through buybacks and liquidity provisioning.

Fee Structure

Creation Fee

Deploying a new token requires payment of 10,000 NOX (approximately $50-100 at current prices). This fee serves dual purposes: funding protocol development and filtering low-quality deployments. The fee transfers directly to the Treasury upon token creation.

ZeroState Pass NFT holders receive a complete fee waiver. Holding any quantity of the NFT grants unlimited free token deployments. This creates genuine utility for the NFT beyond staking boosts while rewarding early ecosystem participants.

Trading Fee

Each buy or sell transaction on the bonding curve incurs a 1% fee calculated on the transaction value. For purchases, the fee applies to the ETH spent. For sales, the fee reduces the ETH returned. The fee collects in ETH and accumulates in the Treasury.

NFT holders receive a reduced 0.5% trading fee, providing ongoing savings for active traders who hold ecosystem NFTs. The fee reduction applies automatically when the trading wallet holds any ZeroState Pass NFT.

Graduation Fee

Upon graduation, 0.5% of the token supply mints to the Treasury as a graduation fee. This one-time fee compensates the protocol for facilitating the transition to decentralized exchange trading. The Treasury may hold, sell, or burn these tokens according to governance decisions.

Treasury Operations

The Treasury executes weekly operations to convert accumulated fees into protocol value. ETH converts to NOX through Uniswap, with slippage protection and TWAP oracles preventing manipulation. The converted NOX then splits according to fixed ratios.

NFT Holder Benefits

ZeroState Pass NFT provides tangible, ongoing value within the Launchpad ecosystem:

Conservative Scenario (Month 1-3)

Growth Scenario (Month 6-12)

Scale Scenario (Year 2+)

Modern application distribution relies on centralized gatekeepers. Apple and Google control mobile software access for billions of users. Microsoft and Apple control desktop distribution. These entities decide what software users can install, extract significant revenue shares, and maintain permanent surveillance over user behavior.

The centralization of software distribution creates systemic risks. Platform policy changes can instantly destroy businesses built on their ecosystems. Controversial applications face removal without recourse. Geographic restrictions fragment the global software market. Privacy-focused applications face particular hostility from platforms whose business models depend on data collection.

Decentralized Distribution

NONOS requires a distribution model aligned with its privacy-first principles. Applications cannot depend on centralized servers for discovery or download. Users must verify software authenticity without trusting third parties. The economic relationship between developers and users should be direct, without intermediary extraction.

The Capsule Marketplace implements these requirements through cryptographic verification, decentralized storage, and token-embedded economics. Applications distribute through IPFS, making them resistant to takedowns and censorship. Ethereum smart contracts provide immutable registries of application metadata and developer credentials. Optional token integration enables new economic models impossible in traditional app stores.

System Architecture

A capsule is a signed archive containing application code, metadata, and optional token configuration. The format supports multiple application types while maintaining consistent verification and installation procedures.

Archive Structure

/capsule.toml          # Manifest with metadata and permissions
/signature.sig         # Developer signature over manifest hash
/icon.png              # Application icon (256x256)
/app/                  # Application-specific contents
  /native/             # NONOS native binaries
  /linux/              # Linux compatibility binaries
  /web/                # Web application bundle
/token.toml            # Optional token configuration

Manifest Format

[capsule]
id = "com.example.myapp"
name = "My Application"
version = "1.2.0"
description = "A privacy-focused productivity tool"
developer = "0x1234...abcd"

[permissions]
network = ["api.example.com"]
filesystem = ["~/Documents/MyApp"]
camera = false
microphone = false

[platforms]
nonos = "native/myapp"
linux = "linux/myapp.AppImage"
web = "web/index.html"

[token]
enabled = true
config = "token.toml"

Permission Model

Capsules declare required permissions in their manifest. NONOS enforces these declarations at runtime through kernel-level sandboxing. Applications cannot access resources beyond their declared permissions.

The Capsule Marketplace enables developers to launch tokens alongside their applications. These tokens integrate with the NOX Launchpad bonding curve mechanism, providing fair distribution and automatic liquidity. Token economics can align developer incentives with user adoption and satisfaction in ways impossible with traditional app stores.

Integration Patterns

Developers choose how tokens integrate with their applications. Common patterns include:

Token Configuration

token.toml

[token]
name = "MyApp Token"
symbol = "MYAPP"
curve_coefficient = 1e-15
graduation_mcap = 69420

[distribution]
creator_allocation = 0          # No pre-mine
initial_liquidity = 0           # Start from zero

[integration]
premium_features = true         # Token unlocks features
governance = true               # Token holders vote on roadmap
revenue_share = true            # Fees distributed to holders

Zero Platform Fees

The Capsule Marketplace charges no fees for publishing or distributing applications. Developers retain 100% of any revenue their applications generate. This contrasts starkly with traditional app stores that extract 15-30% of all transactions.

The only fees in the system are bonding curve trading fees for applications that choose token integration. These fees flow to the NOX Treasury, supporting the broader ecosystem. Applications without tokens incur no fees whatsoever.

The staking protocol allows NOX holders to lock tokens for specified durations, earning a share of protocol fees proportional to their stake weight. Longer lock periods earn higher multipliers, incentivizing long-term commitment to the ecosystem and reducing circulating supply.

Lock Period Boosts

Stakers can choose flexible (no lock) staking or lock their tokens for enhanced rewards. Lock boosts multiply the base APY, rewarding long-term commitment. Combined with NFT boosts, stakers can achieve up to 6.25x total multiplier on their rewards.

NFT Boost System

ZeroState Pass NFT holders receive multiplicative boosts on their staking rewards. The NFT boost stacks with lock period boosts for maximum yield optimization.

Staking Contract

NoxStaking.sol

function stake(uint256 amount, uint256 lockDuration) external {
    require(lockDuration >= MIN_LOCK, "Lock too short");
    require(lockDuration <= MAX_LOCK, "Lock too long");

    uint256 multiplier = calculateMultiplier(lockDuration);
    uint256 weight = amount * multiplier / PRECISION;

    stakes[msg.sender].push(Stake({
        amount: amount,
        weight: weight,
        lockedUntil: block.timestamp + lockDuration,
        lastClaim: block.timestamp
    }));

    totalWeight += weight;
    noxToken.transferFrom(msg.sender, address(this), amount);

    emit Staked(msg.sender, amount, lockDuration, weight);
}

NFT Holder Bonuses

ZeroState Pass NFT holders receive enhanced staking benefits across all lock durations:

The Treasury executes weekly reward distributions. All accumulated fees convert to NOX through Uniswap, then split according to protocol parameters. The 20% staker allocation distributes proportionally to stake weights across all active positions.

Reward Calculation

Rewards accrue continuously but claim weekly. NFT holders can claim daily. Unclaimed rewards remain in the contract, accumulating until claimed. Users can optionally compound rewards by restaking claimed NOX into new positions.

Privacy-Preserving Claims

The staking contract supports optional privacy-preserving reward claims through integration with privacy protocols. Stakers can withdraw rewards to fresh addresses without on-chain linkage to their staking address. This prevents third parties from profiling staker behavior or estimating net worth.

function claimPrivate(
    bytes calldata proof,
    address recipient
) external {
    uint256 rewards = calculateRewards(msg.sender);
    require(verifyPrivacyProof(proof, rewards), "Invalid proof");

    stakes[msg.sender].lastClaim = block.timestamp;
    noxToken.transfer(recipient, rewards);

    emit RewardsClaimed(bytes32(0), rewards); // No address logged
}

Projected Returns

Returns depend on total staked amount and protocol activity:

Returns are not guaranteed and depend entirely on protocol usage. Higher protocol activity generates higher fees; more staked NOX dilutes per-token returns.

Stakers vote on protocol parameters with voting power equal to their stake weight. Governance proposals require quorum and supermajority to pass. Governance operates through timelock: approved changes take effect after 7-day delay.

The protocol operates in an adversarial environment where rational actors will exploit any profitable vulnerability. Security design assumes sophisticated attackers with significant capital, technical expertise, and MEV infrastructure.

Threat Categories

Smart Contract Security

Reentrancy Protection

All state-changing functions follow the checks-effects-interactions pattern. External calls occur only after all state updates complete. Critical functions additionally use reentrancy guards.

modifier nonReentrant() {
    require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
    _status = _ENTERED;
    _;
    _status = _NOT_ENTERED;
}

Access Control

The protocol minimizes privileged operations. No admin can pause trading, modify curve parameters, or access user funds. The only privileged operation is Treasury parameter adjustment, protected by timelock and governance multisig.

Risk Disclosure

Smart Contract Risk

Despite audits and testing, smart contracts may contain undiscovered vulnerabilities. Exploits could result in partial or total loss of funds deposited in the protocol.

Market Risk

Tokens launched through the protocol have no guaranteed value. Most launched tokens will likely decrease in value over time. Early participation does not guarantee profit.

Regulatory Risk

The regulatory status of token launches remains uncertain in most jurisdictions. Regulatory actions could affect protocol operation or token tradability.