NexumRise Token (NBES) — Smart Contract Audit Report

Executive Summary

The NexumRise NBES token contract underwent a structured iterative audit across eight sequential versions (V2.9 → V2.16). Each round followed the same discipline: issues reported → developer fixes in isolation → new version submitted for re-audit and fix verification before the next pass began.

Seven findings were identified and resolved across the audit cycle. No findings remain open in the final V2.16 release. The contract is production-ready from a smart contract security standpoint:

• Critical findings: 0 • High findings: 0 • Medium findings: 3 (all resolved) • Low findings: 4 (all resolved) • Informational / documented design decisions: several (no action required)

The contract implements a sophisticated architecture — formula-driven bonding curve pricing, dual-reserve fund separation, five-layer liquidity trap protection, commit-reveal oracle governance, dual-signer emergency paths, and a 30-day holder rescue mechanism — and does so with consistent application of CEI (Checks-Effects-Interactions), return bomb protection, reentrancy guards, and on-chain governance timelocks. The security posture at V2.16 is strong.

V2.16 IS CLEARED FOR DEPLOYMENT ON ETHEREUM MAINNET.

1. Contract Overview

1.1 Purpose

NBES is a fee-on-transfer ERC-20 token with a fully on-chain bonding curve. Users buy and sell directly against the contract at a formula-derived price — there is no Uniswap pool or AMM. Price is determined by a volume-weighted formula over BTC, ETH, and SOL Chainlink oracle feeds.

1.2 Pricing Formula

NBES Price (Wei) =
  (BTC_wei × 50% × VW_btc) + (ETH_wei × 30% × VW_eth) + (SOL_wei × 20% × VW_sol)
  ──────────────────────────────────────────────────────────────────────────────
                            totalSupply / 100

Where:
  BTC_wei = (BTC_usd_1e8 × 1e18) / ETH_usd_1e8
  ETH_wei = 1e18  (ETH is always 1 ETH = 1e18 Wei)
  SOL_wei = (SOL_usd_1e8 × 1e18) / ETH_usd_1e8
  VW_xxx  = asset 24h volume / (BTC+ETH+SOL total volume)  [1e18-scaled]

Price is entirely Wei-native. No USD arithmetic exists on-chain.

1.3 Reserve Architecture

The two reserves share address(this).balance but are ring-fenced via the investmentReserve accounting variable. getMainReserve() = address(this).balance − investmentReserve.

1.4 Key Mechanisms

2. Audit Scope and Methodology

2.1 Versions Reviewed

2.2 Methodology

Each review performed full source-level reading of the entire contract. Every identified issue was documented with exact line references, attack path or failure mode, severity rationale, and a concrete code fix. The following version re-verified fix correctness before beginning the next pass.

Areas covered per version: constructor and genesis state, oracle read paths, buyNBES() and sellNBES() (slippage, CEI, oracle call count), migration functions, emergency withdrawal paths, rescue mechanism, milestone burns, governance timelocks, ERC-20 standard functions, event integrity, return bomb protection, and reentrancy coverage.

3. Findings

Flag set moved to AFTER _executeMilestoneBurn() completes successfully. Each milestone can now only execute once.

BEFORE: milestone1Burned = true;  // set before execution — rolls back on revert
        _executeMilestoneBurn(1, M1_BURN, BURN_M1);

AFTER:  _executeMilestoneBurn(1, M1_BURN, BURN_M1);
        milestone1Burned = true;  // set only after success ✅

Single formulaWei = getBuyNBESPrice() call at top of buyNBES(). Spread and buy price derived inline from the cached value.

uint256 formulaWei  = getBuyNBESPrice();  // exactly 1 oracle round-trip ✅
uint256 spreadAmt_  = (formulaWei * buySpreadBps) / FEE_DENOM;
uint256 buyPriceWei = formulaWei + spreadAmt_;
// reuse formulaWei for spread accounting — zero extra oracle reads

signerApprovedMigration = false added to both cancelMigration() and executeMigration().

function cancelMigration() external onlyOwner {
    migrationInitiated      = false;
    migrationAt             = 0;
    signerApprovedMigration = false; // FIX: stale approval cleared on cancel ✅
    emit MigrationCancelled(_msgSender());
}

Orphaned stubs removed. Function implementations now immediately follow their documentation.

require(!migrationInitiated, ...) guard added to setSuccessor(). Combined with F-3 fix, cancelling migration now also clears the stale approval, forcing fresh dual-approval for any new destination.

function setSuccessor(address _successor) external onlyOwner {
    require(_successor != address(0),    'NBES: Zero address');
    require(_successor != address(this), 'NBES: Cannot migrate to self');
    require(!migrationInitiated,
        'NBES: Cancel active migration before changing successor'); // FIX ✅
    successor = _successor;
}

Check moved to immediately after Phase 2 redirect calculation (which finalises ethOutWei) and BEFORE the // -- EFFECTS block. Zero state writes on slippage revert.

// Phase 2 finalises ethOutWei
if (reserveFeedEnabled && _totalSupply <= MIN_SUPPLY && ethOutWei > 0) {
    redirectFeeETH = (ethOutWei * burnFee) / FEE_DENOM;
    ethOutWei      = ethOutWei - redirectFeeETH;
}
// V2.15 FIX: slippage check — zero SSTOREs on revert ✅
require(ethOutWei >= minETHOut, 'NBES: Slippage exceeded -- price moved');
// -- EFFECTS (all state writes begin here) --

investmentReserve = 0 added after flag resets, before the assembly ETH transfer.

uint256 amount = address(this).balance;
mainResEmergencyInitiated = false;
ownerApprovedMainEmerg    = false;
signerApprovedMainEmerg   = false;
investmentReserve         = 0;   // FIX: zero phantom reserve ✅
emit MainResEmergencyExecuted(amount);
bool ok;
assembly { ok := call(gas(), caller(), amount, 0, 0, 0, 0) }
require(ok, 'NBES: Transfer failed');

4. Findings Summary

✓ All 7 findings resolved. Zero open findings in V2.16.

5. Security Architecture Assessment

5.1 Access Control

• onlyOwner guards all administrative functions
• Governance timelocks: 24h on fee/spread/toggle changes; 48h on reserve withdrawals, feed updates, migration
• All critical operations (emergency withdrawal, migration, rescue, main-reserve emergency) require dual approval from owner AND trustedSigner before countdown begins
• setTrustedSigner() uses propose-then-accept model — candidate must call acceptTrustedRole() from their own wallet, proving distinct key control
• Founder tokens locked 1 year via founderUnlockTime, enforced in _transfer()

5.2 Oracle Security

5.3 Reentrancy

• nonReentrant modifier on all ETH-moving functions: buyNBES(), sellNBES(), executeReserveWithdraw(), executeEmergencyWithdraw(), executeMainReserveEmergency(), executeMigration(), claimRescueETH(), seedReserve(), depositRevenue()
• CEI (Checks-Effects-Interactions) strictly observed: all state writes complete before ETH transfers in every function
• receive() reverts unconditionally — no accidental ETH routing

5.4 ETH Reserve Protection

• Ring-fencing: investmentReserve variable separates the two pools; main reserve never directly accessible to owner except via 60-day dual-sig path
• ETH crash protection: if ETH drops >5% in 24h, sell price adjusted by drop%. Applied to base price only — premium self-adjusts via investmentReserve valuation
• Five-layer liquidity trap: (1) Circuit breaker — permissionless trigger, 1-hour cooldown; (2) Progressive stress fee — 0% → 1% → 3% as health drops; (3) 24h exit window — max 10% of reserve per window; (4) Max single sell — 5% of reserve per tx; (5) Reserve health tiers — HEALTHY / CAUTION / WARNING / CRITICAL
• Reserve premium safety cap: premiumPerToken capped at investmentReserve / circulatingNBES — total implied premium can never exceed actual reserve balance

5.5 Holder Rescue Mechanism

• Dual-signer (owner + trustedSigner) approval required to initiate
• 30-day timelock before claims open; 7-day snapshot recording window
• 7-day prior hold requirement prevents last-minute rescue buyers from claiming
• ETH claim locked at snapshot time (not claim time) — claim order irrelevant; all holders receive equal proportional share
• Rescue epoch counter (rescueEpoch++ on cancel) invalidates all prior snapshot mappings without gas-intensive iteration
• Rescue intentionally overrides 500M floor — emergency redemption takes precedence over burn protection

5.6 Documented Design Decisions (Informational — No Action Required)

6. Conclusion

NexumRise NBES V2.16 completes a seven-finding iterative audit cycle with all issues resolved. The contract correctly implements a novel formula-driven bonding curve with comprehensive liquidity protection, dual-reserve architecture, on-chain governance with community-visible timelocks, and a last-resort holder rescue mechanism.

The three medium findings addressed fundamental invariants: milestone irreversibility, oracle call efficiency, and migration authorization integrity. The four low findings addressed gas safety, event/data accuracy, and accounting consistency. No critical or high severity issues were identified at any stage.

V2.16 IS CLEARED FOR DEPLOYMENT ON ETHEREUM MAINNET.