NexumRise NBES — Architecture Summary

Document control

1. Purpose of this document

This summary is written for smart contract auditors and security reviewers. It describes the intended split of the NBES monolith into multiple contracts to:

1. Satisfy EIP-170 (24,576-byte deployment limit).
2. Separate fund-moving logic from governance / emergency logic.
3. Define trust boundaries, audit scopes, and in-scope attack surfaces per contract.

Auditors should treat v2.16 / v2.16.1 monolith as the historical implementation baseline and this document as the target architecture for v2.16.2+ unless otherwise stated in the engagement letter.

2. Executive summary

3. System diagram (logical)

4. Contract inventory

5. Audit scope by contract

5.1 NexumRiseCore — CRITICAL PATH

Must verify:

Explicitly out of Core (moved to Admin): 39× propose/execute/cancel governance externals, dual-sig approval flows, migration.

5.2 NexumRiseAdmin — GOVERNANCE & EMERGENCY

Not in Admin: Pricing math, buyNBES/sellNBES execution.

5.3 NexumRiseRescue — OPTIONAL

5.4 NexumRiseView — INFORMATIONAL

• No state changes, no ETH.
• Verify it cannot be used to trick users (phishing address risk is operational, not contract).
• Incorrect display math is off-chain risk only.

6. Trust model (auditor checklist)

Key trust assumption: Compromised Admin or malicious owner can drain reserves via emergency paths after timelock/dual-sig — by design (governance trust). Auditors should flag whether timelocks are sufficient for token holder expectations.

7. Cross-contract API (Core surface for Admin/Rescue)

Admin-only setters (representative — full list in ARCHITECTURE.md):

Primary audit question: Can any address other than admin / rescue invoke these? Can Admin be swapped without holder notice?

8. State ownership (summary)

9. Events (indexing guidance)

Auditors: confirm no sensitive ops lack events on Core.

10. Known monolith issues relevant to split

11. Out of scope (typical engagement)

• Frontend / MetaMask phishing
• Chainlink liveness and off-chain feed compromise
• Legal / securities classification
• Economic model (formula fairness to holders)
• Centralization of owner/signer keys (operational)

12. Recommended audit workplan

13. File references

14. Module → contract quick reference

15. Implementation recommendations

Consolidates implementation notes with architecture review. Required for v2.16.2, not optional.

15.1 A — One-time setAdmin handshake

function setAdmin(address _admin) external onlyOwner {
    if (adminInitialized) revert NBESAdminAlreadySet();
    if (_admin == address(0)) revert NBESZeroAddress();
    admin = _admin;
    adminInitialized = true;
}

Audit focus: Can setAdmin be called twice? Can non-owner set admin? Is Admin address correct before any trading?

Caveat: Renouncing Core ownership breaks seedReserve, depositRevenue, and one-time setRescue unless moved to Admin.

15.2 B — NexumRiseConstants.sol

Single import for INITIAL_SUPPLY, MIN_SUPPLY, staleness windows, FEE_DENOM, tier %, timelocks, volume bounds — used by Core, Admin, View, Rescue.

Audit focus: No mismatched constants between contracts (especially View vs Core pricing display).

15.3 C — onlyAdmin / onlyRescue on all Core setters

Primary audit question: Can any EOA call Core setters directly and bypass Admin timelocks? Use custom errors (NBESNotAdmin, NBESNotRescue) per v2.16.1.

15.4 D — Phased deployment

Before mainnet: Monolith v2.16 behavior parity matrix (regression tests).

15.5 Owner vs Admin vs Rescue

15.6 Launch checklist

• Core + Admin + View (+ optional Rescue) compile under EIP-170
• setAdmin one-time + adminInitialized
• All Core setters have onlyAdmin or onlyRescue
• NexumRiseConstants.sol imported everywhere
• Parity tests vs v2.16 monolith
• Emergency paths documented for holders