Implementation Status and Evidence Register¶
Snapshot: October 9, 2026. This is an evidence register, not an acceptance certificate. Exact repository revisions below are the sources inspected; they are not proof of the binary deployed on a particular device. Source/test files were inspected through GitHub; this review did not run the full native test suite, deploy infrastructure, audit contracts, or reproduce GPU benchmarks.
Status vocabulary¶
- Source present: Implementation files exist and identifiable tests may exist; no claim of a passing current CI run or production availability.
- Project-reported complete: Project leadership/planning states completion; audit, deployment, and load tests are separate evidence.
- Partial / prototype: Narrow functions or earlier POCs exist but the full end-to-end product requirement is not demonstrated.
- Specified / planned: Design and roadmap exist; no source-backed completed integration is established.
- Unverified externally: Public audit, deployment, benchmark, economics, or operational evidence not supplied to this review.
Versioned evidence table¶
| Component | Owner / source inspected | Code or tests found | Current status and boundary |
|---|---|---|---|
| SuperGenius native mainnet | SuperGenius develop at fd41947 |
Ledger, CRDT, native processing, consensus, genesis/quorum and escrow source; account and processing test files | Project-reported implementation complete. Public mainnet not launched; no end-to-end production claim follows. |
| Native token precision | TokenAmount.hpp and tests | PRECISION = 6, token amount arithmetic and tests |
Source present: 1 GNUS = 1,000,000 native Minions. EVM precision needs separate contract review. |
| Native burn and trust rules | BurnConfig.hpp, TrustedPeerRegistry.hpp | 100-basis-point genesis default and quorum-managed policy; focused test files | Source present. Default is not a deployed setting or a fixed 10% burn. |
| Consensus / validator roles | ValidatorRegistry.hpp, consensus tests | Weighted roles and vote/quorum logic | Source present; not accurately summarized as an unrestricted two-thirds reputation vote. |
| Native work estimate and escrow | GeniusNode.cpp, TokenAmount.hpp | Existing general-processing quote uses a work proxy and GNUS/USD conversion | Source present; block_len unit interpretation needs checking; not a measured GPU-hour. |
| Processor runtime | SGProcessingManager main 89d161b |
MNN LLM and other processors; focused processor test files | Source present; existing processor is not proof that the proposed ELM job bridge is live. |
| NEO-SWARM ELM/router core | NEO-SWARM pinned 4371205 |
src/elm/, src/router/, src/core/engine/, test/elm/, test/router/ |
Partial/source present. Phase 7 ELM/router work is marked complete in its own workstream; do not infer final GCS controller deployment or quality. |
| NEO-SWARM durable GAML memory | src/memory/memory_init.cpp |
Explicit placeholder; Phase 8 work re-planned | Specified / not implemented there; do not describe full governed long-term memory as delivered. |
| Distillation/benchmark POC | NEO-SWARM gnus-poc/ |
Python training, routing and benchmark/test scaffolding | Prototype/source present; no independent measured result or iPhone 7 performance certified here. |
| GCS Chat foundations | GCS main 0282eec and app roadmap |
C++ GlobalDB, messaging, FFI, Flutter UI, source tests | Partial/source present. App roadmap shows phases 1–3 of 7 done; membership, moderation, bot and discovery not complete. |
| Full GCS system integration | System STATE.md |
15-phase workstream, 0 completed | Specified / planning. Do not confuse with narrower NEO-SWARM or Chat progress. |
| GCS GAML memory / secure tool intermediary / arbitration | system roadmap | Phase 2/3/14 plans; no completed workstream milestone | Specified / planned in the full GCS system. |
| GCS OpenAI-compatible gateway | API specification, system roadmap | Phase 6, 9 questions remain open | Specified / planned; not a working public retail API. |
| Distributed ELM job funding | SuperGenius #369, bridge | One native Task, multiple elms[] work items, single escrow specified |
Specified / unfinished; pooled versus per-ELM funded hour metering unresolved. |
| GCS execution integrity (EIS) | EIS design, system roadmap | Draft, seven open numerical/policy questions; Phase 15 gated | Specified / draft-gated, not demonstrated heterogeneous GPU verification. |
| EVM token contracts | published contracts, Solidity repo | EVM source and address links | Separate from public native-mainnet launch. Deployed bytecode, issued/circulating supply and supply mirrors need chain-by-chain verification. |
| Independent security audit | Contracts/audit listing | One dated Solidproof smart-contract PDF (Feb 24, 2024) listed | Scope-limited evidence; no posted independent C++ node/GCS production audit found in the reviewed public docs. |
Conflicts and gaps requiring owner action¶
- Progress reporting: GCS Chat STATE structured fields show 43% while its narrative says 95%. NEO-SWARM STATE also contains different milestone/plan counts and references; resolve with workstream owners rather than averaging numbers.
- Mainnet: Leadership reports code complete, but production operation, independent audit, service-level uptime, and large node scale require separate proof.
- Consensus: TrustedPeerRegistry, BurnConfig policy quorum and ValidatorRegistry weighted slot quorum have distinct scopes; historical FAQ's universal reputation vote was wrong.
- Floating-point reproducibility: EIS specifies determinism classes and tolerances, but this review did not find a published cross-GPU signed attestation dataset. The legacy verifier slicing pseudocode is not a deployed protocol proof.
- Public API economics:
$0.0003 per funded processing-houris a planned ELM-job design rate, not a live tariff. Job-hour pooling/aggregation remains undecided. - Security: Publish completed audit scope and dates; label unaudited components accurately.
- Commercial diligence: Four-chain outstanding EVM supply can be computed directly as the sum of
totalSupply()/10^18for the published Ethereum, Polygon, BNB Chain and Base GNUS contracts. Circulating/treasury balances, possible transfer mirrors and revenue/valuation claims are different questions and need separate evidence. See the calculation below.
Four-chain EVM token supply: direct read recipe¶
Read the Diamond proxy on each mainnet, not merely a block explorer's displayed 'maximum supply' or a market-data site's circulating figure. GNUS combines ERC-20 and ERC-1155 interfaces; the GNUS ERC-20 facet in GNUSBridge.sol declares 18 decimals and implements totalSupply() by returning totalSupply(GNUS_TOKEN_ID). Do not sum both interface views; they refer to the same GNUS token supply on a chain.
| Network | Chain ID | Diamond address |
|---|---|---|
| Ethereum | 1 | 0x614577036F0a024DBC1C88BA616b394DD65d105a |
| Polygon | 137 | 0x127E47abA094a9a87D084a3a93732909Ff031419 |
| BNB Chain | 56 | 0x614577036F0a024DBC1C88BA616b394DD65d105a |
| Base | 8453 | 0x614577036F0a024DBC1C88BA616b394DD65d105a |
Use eth_call with selector 0x18160ddd (ERC-20 totalSupply()) and 0x313ce567 (decimals()) at a recorded block for each chain. Divide each returned integer by 10^18, then add all four amounts using integer arithmetic before converting to a human-readable decimal. Write down each block number, timestamp, endpoint, raw hex result, decoded integer, and final sum. Where the Diamond does not expose a facet through that selector, inspect its active louper facets and call ERC-1155 totalSupply(uint256) with GNUS_TOKEN_ID instead; never treat an RPC error as zero.
totalSupply() reports minted minus burned supply on that chain, including treasury and locked holdings. Supply in different deployments is counted once per deployment in this four-chain figure; if a later bridge creates wrapped representations of the same economic assets, also publish any adjusted deduplicated figure and the matching bridge ledger. Testnet and BRC-20 assets are excluded from this four-chain EVM subtotal.
User-reported live eth_call snapshot (October 8, 2026): The owner executed the Python RPC script against the four listed networks and supplied the following decoded results. These are user-reported outputs; the original block heights, raw RPC payloads and transaction-independent logs were not attached to this audit.
| Mainnet | Reported totalSupply()/10^18 (GNUS) |
|---|---|
| Ethereum | 970,018.513038 |
| Polygon | 14,943,848.730392 |
| Base | 250,000.000000 |
| BNB Chain | 1,000,000.000000 |
| Four-chain outstanding EVM supply | 17,163,867.243430 |
The sum agrees arithmetically with the supplied four values. Treat it as a dated outstanding on-chain supply snapshot, including treasury/locked balances—not circulating supply, not a permanent supply cap, and not a forecast. For fully reproducible third-party evidence, retain each chain's block number, raw hexadecimal return and decimals value on the next read.
Evidence standard for upgrades¶
To promote a row to tested, attach an identified CI workflow or test command plus results, environment, commit and date. To promote it to deployed, add endpoint or public deployment identifier, node/build version, release date, monitoring evidence and access scope. To claim a benchmark, use the protocol in Performance Benchmarks. Never make those promotions from prose, file names or planning checkboxes alone.