SOURCE REVIEW / ECONOMIC PARITY / DELIVERY EVIDENCE

From Agent Mech to NEXORA.

A source-led analysis of the reference collectible and the original NEXORA implementation. This is an internal engineering review and test record, not an independent security certification.

1. What the reference actually does

The provided Sourcify record identifies AgentMech.sol:AgentMech, compiled with Solidity 0.8.24 and optimization enabled with 200 runs. Sourcify reports exact creation and runtime matches. The reviewed source is a collectible NFT contract, with no staking, yield, referral rewards, redemption pool, or fungible project token.

2. The exact rarity mechanism

The source comments omit a key distinction: paid mints 2–4 have a Rare floor. If the ordinary roll would be Common, the paid-card flag upgrades it to Rare. This changes the paid distribution.

These are nominal seed-threshold probabilities. They describe the code's classification, not a promise of unbiased outcomes or an exact final collection distribution.

The original snapshot contained 694 Common, 207 Rare, 78 Epic, 20 Legendary and 1 Mythic NFT. These counts reconcile to the full 1,000 supply. One Mythic establishes that one address reached its fifth mint; the aggregate counts alone do not establish the full paid-mint history.

3. Business model and money flow

A collector can claim one free NFT by paying network gas, then optionally complete the five-card sequence for 0.0062 BNB in mint payments. Paid cards have a higher rarity floor, and the fifth card offers a deterministic collection milestone.

For a sold-out 1,000-piece edition, total primary mint receipts range from 0 BNB if all pieces are first mints to a mathematical maximum of 1.24 BNB if 200 addresses each complete five mints. These are model bounds, not measured reference revenue or a forecast. Secondary sale royalties are separate and voluntary at the marketplace level.

The normal mint flow does not retain BNB in the NFT contract. A zero contract balance therefore does not mean zero revenue. Actual cumulative receipts require complete mint-event or transaction coverage; this review does not invent a revenue figure from incomplete public RPC history.

There is no investment return mechanism. The commercial value of the model comes from the artwork, access to a recognizable identity community, collectibility and distribution. It does not arise from an internal yield engine.

4. Findings and retained limitations

Cosmetic rarity can be influenced

The entropy combines the previous block hash, prevrandao, caller and timestamp. It is not verifiable secure randomness. Validators and sophisticated callers may influence or select outcomes, and a smart contract can revert an unfavorable mint. NEXORA retains this original mechanism and explicitly labels rarity as cosmetic. It must not be advertised as a fair prize draw. Moving to VRF would be a material protocol change and is not silently introduced.

The identity gate is not a one-person limit

The check uses the current caller's balanceOf at the external identity collection. There is no consumed identity-token registry, personhood proof or per-ID quota. A transferable identity can qualify successive addresses, and transferred-in collectibles do not consume the recipient's mint quota. NEXORA preserves these semantics.

The seven-day clock starts immediately

Deployment begins the window. There is no administrator to postpone launch, reopen minting, or correct a bad payment recipient. Production addresses, network and source artifacts must be verified before deployment. The original deployed at October 26, 2026 04:07:41 UTC+8, with a scheduled expiry of November 2 at the same time; it sold out earlier.

External identity and recipient dependencies

An identity-contract failure can prevent minting. A creator contract that rejects BNB blocks paid minting, with the whole transaction reverting. Neither project has an alternate payout path. NFTs received by contracts must also respect ERC-721 receiver behavior in NEXORA.

Transfers and royalties

Transferring an NFT clears its token-specific approval and does not reset lifetime mint counts. Holders can transfer without holding Agent ID. ERC-2981 advertises the royalty recipient and amount; it cannot force a marketplace or peer-to-peer buyer to pay the royalty.

5. Deliberate implementation differences

The collection's economic rules are preserved. The implementation is not a byte-for-byte clone, because it has a separate brand, original artwork, and specific protective changes:

• OpenZeppelin ERC-721 replaces the handwritten token implementation. Minting to contracts now requires an ERC-721 receiver callback.
• A reentrancy guard blocks nested minting from NFT receiver or payout callbacks. The entire batch quota and supply are reserved before callbacks.
• quote and priceOf reject invalid quantities and ordinals. The reference can return values for invalid quotes that cannot actually mint.
• The identity address is immutable and supplied at construction for local testing; the production deploy script pins it to the same reference identity address.
• NEXORA provides a Minted event, original SVG metadata, and standard error behavior. The entropy packing, paid-card flags and rarity thresholds preserve the reference mechanism.
• The English frontend verifies the expected network and runtime bytecode hash, reads wallet-specific data only after connection, and disables writes when state cannot be verified.

6. Verification evidence

Contract tests exercise the staircase price, eligibility failures, exact payment checks, paid-card rarity floor, fifth-card guarantee, lifetime quotas after transfer, supply boundary, exact expiry, metadata JSON/SVG, interface support, royalties, payment rollback, non-receiver rejection and callback reentrancy protection. Differential tests execute the original source and NEXORA side by side over multiple batch splits and exhaustively compare all 1,000 rarity threshold values for free, paid and Mythic flags.

Browser tests cover English-only rendering, desktop/mobile widths, rarity filters, preview labeling, quantity bounds, no-wallet handling, rejected wallet connections and transactions, wrong-chain switching, identity checks, an actual local-chain five-card mint with payment and metadata reads, account changes, disconnects, and failure on unexpected runtime code. These use an isolated Ganache chain; they do not spend mainnet funds or invent mainnet mint receipts.

Production verification is a separate step: chain ID 56, transaction receipt, runtime comparison with immutable regions accounted for, constructor addresses, collection constants, initial supply, deployment timestamp and frontend configuration must be checked against the deployed contract. Source verification through Sourcify is reported only after the verification service returns a match.

7. Hosting and key handling

NEXORA is a static frontend isolated from the existing V9 applications. Only the public web bundle is uploaded to the server. Private keys remain in the local Desktop wallet folder and are excluded from the web root and source publication. The deployment account pays gas; the separate creator account receives mint proceeds and optional royalties. Neither account is an on-chain administrator.

8. Completed deployment and final review

All 46 final checks passed: 13 contract tests, 8 comparisons against the original source, 14 wallet/UI checks and 11 live production checks. Core pricing, supply, identity gating, lifetime quotas, rarity thresholds, mint timing and direct payments match the reference. The protective implementation differences listed above remain deliberate.

Deployment transaction: 0x1fee8242406395c78c77adf514a048e0c1151172e150687520486f374cd0d466. Deployment used 0.00011326815 BNB. The six existing V9 business services retained their process IDs and active states across the website deployment. No real user mint was executed by the deployment tooling; end-to-end mint testing used an isolated local chain.