CoZ Proof of Working 2.7

CoZ Proof of Working 2.7.md

ProofOfWorking 2.7 Report - HushForge Speculation Tokens And Trust Signals

Project: HushForge / Neo N3 Token Launcher
Date: 2026-05-24
Status: Product implementation and private-chain validation complete for direct speculation creation, Forge Audit Index, and ForgeScore. Neo TestNet deployment is not completed yet and remains the next public validation step.

Executive Summary

ProofOfWorking 2.7 moves HushForge from a community-token-first launcher toward a direct speculative-token launchpad.

The main progress is:

• A public Neo standards proposal was opened for a multi-fungible token interface where one deployed contract can expose many independent fungible token identities.
• HushForge now supports native speculative token creation directly from the Forge flow.
• HushForge now includes automated market trust signals: Forge Audit Index and ForgeScore.
• Local/private-chain validation has passed for the direct speculative creation path.
• Neo TestNet deployment of the Forge contracts has not happened yet, but is the next scheduled milestone.

This report should not be read as a TestNet deployment announcement. The current public-ready claim is: the feature is implemented and validated on the local/private Neo3 chain, and the public standardization work has started.

Public Standardization Work

Neo Multi-Fungible Token Standard PR

Public PR:

• neo-project/proposals#232 - Draft: Multi-Fungible Token Standard

Current PR facts checked on 2026-05-24:

• State: OPEN
• Author: aboimpinto / Paulo Aboim Pinto
• Branch: draft/multi-fungible-token-standard
• Base: neo-project/proposals:master
• Created: 2026-05-22 UTC

The proposal follows the discussion from:

• neo-project/proposals#146 - Multi Token Standard

The important product point for HushForge is not ERC-1155-style batching. Neo can already compose multiple invocations inside transactions. The HushForge problem is different:

Current Neo standards do not provide a wallet/indexer-standard way for one deployed contract to expose many independent fungible token identities without deploying one NEP-17 contract per token.

The draft proposes a token-id-aware fungible interface where wallets and indexers treat the asset identity as:

contractHash + tokenId

This would let a launcher-style platform create many fungible token identities through one deployed contract while preserving a standard surface for metadata, balances, supply, transfer events, and receiver callbacks.

Why This Matters For HushForge

HushForge currently uses the wallet-compatible path: one NEP-17 token contract per token. That is compatible with the current Neo ecosystem, but it keeps the per-token deployment cost.

The measured FEAT-111 evidence showed the gap:

Path	Wallet/indexer standard today?	Per-token cost
Full NEP-17 token creation through TokenFactory	Yes	13.95593220 GAS
Ultra-lean NEP-17 facade plus shared engine	Yes	12.19824780 GAS
Shared master/engine registration only	No, needs standard support	0.43633510 GAS

The standard PR is therefore the long-term path for dramatically cheaper token creation. Until the ecosystem has a standard for this, HushForge will continue using the existing one-token-per-NEP-17 model for user-facing speculative tokens.

Product Work Completed

Native Speculative Token Creation

HushForge creators can now choose Speculative directly in the token creation flow instead of creating a Community token first and activating trading later.

The direct speculative creation flow:

• Keeps Community as the default creation mode.
• Lets the creator select Speculative as an explicit opt-in mode.
• Collects the market launch parameters during creation:
  • quote asset, currently GAS by default;
  • launch profile, such as starter/standard/growth/flagship;
  • curve inventory, defaulting to the initial token supply unless the creator keeps inventory outside the curve.
• Sends the TokenFactory-supported speculation payload:

[name, symbol, supply, decimals, "speculation", imageUrl, creatorFeeRate,
 quoteAsset, curveInventory, launchProfile]

After the wallet signs and the transaction confirms, HushForge parses the created token hash and routes the creator directly to:

/markets/{contractHash}

This creates the user-facing behavior we need for speculation tokens: create the token and immediately land on the public market.

Forge Audit Index

Forge Audit Index is an automated contract-fact score from 0 to 100.

It is not an external security audit and does not claim that CoZ, Neo, HushNetwork, or any third party audited the contract.

The purpose is to show investor-facing owner-control and contract-risk facts clearly:

• Was the token created through the Forge factory?
• Is the token using a known Forge profile?
• Is the contract still mutable or locked?
• Can the owner mint more supply?
• Is max supply capped or uncapped?
• Did the creator retain inventory outside the curve?
• Are creator fees, platform fees, or burn rates active?
• Which owner lifecycle controls remain available?

The score is intentionally explainable. A low Audit Index does not mean the token is broken; it means the owner still has controls that could affect investors.

ForgeScore

ForgeScore is separate from the Forge Audit Index.

Forge Audit Index answers:

How much owner-control and contract-risk surface is visible?

ForgeScore answers:

How active or interesting does the market look from available data?

The first version is conservative and uses direct-RPC/baseline data only:

• tradable status;
• graduation progress;
• trade count when available;
• curve depth;
• market age.

The score includes a confidence label. Current confidence is Baseline until indexer-backed market history is available.

Future indexer-backed scoring should include:

• 24h volume;
• 24h trade count;
• holder count;
• holder concentration;
• recurring trader count;
• age-adjusted momentum.

Validation Evidence

Most recent FEAT-145 validation:

hush-forge:
npm run test:run -- wallet-invocation-requests.test.ts forge-service.test.ts
Result: PASS, 22 tests.

hush-forge private-chain Playwright:
npx playwright test --config e2e/integration/playwright.harness.config.ts -g "Direct speculation creation"
Result: PASS, 1 focused private-chain test.

hush-forge:
npm run test:run
Result: PASS, 66 files / 538 tests.

hush-forge:
npm run lint
Result: PASS.

hush-forge:
npm run build
Result: PASS.

The focused private-chain Playwright flow proved:

• wallet harness connection;
• direct Speculative creation selection;
• real TokenFactory payment transaction signing;
• transaction confirmation;
• parsing of the created contract hash;
• redirect to /markets/:hash;
• visibility of the post-launch banner, Forge Audit Index, ForgeScore, and trading rail.

No hush-neo-contracts code changed in this ProofOfWorking checkpoint. Contract regression was not rerun during final FEAT-145 validation. The existing contract-level proof remains the direct speculation bonding-curve test:

BondingCurveRouterTests.DirectSpeculationLaunch_RegistersCurveAndMovesExactInventory

Public Code Reference Status

The standardization work is already public:

• neo-project/proposals#232

The HushForge implementation is currently on the local feature branch:

feat/FEAT-145-direct-speculation-launch-forge-audit-score

Before posting the final CoZ update, this report should be updated with:

• public HushForge branch or commit link;
• public CI run link if available;
• any final TestNet contract addresses and transaction hashes.

TestNet Deployment Status

Neo TestNet deployment is not complete yet.

Planned next steps:

1. Deploy or update the HushForge TokenFactory and related market contracts on Neo TestNet.
2. Configure the Forge frontend against the TestNet contract hashes.
3. Run a real TestNet smoke:
   • create a speculative token;
   • confirm the token appears in /markets;
   • perform a small buy/sell flow if TestNet balances allow it;
   • verify Forge Audit Index and ForgeScore render from TestNet reads.
4. Record the deployed contract hashes, deployment transactions, and smoke transaction hashes.
5. Update this report before sharing it as a final external milestone.

Until this is done, the correct external wording is:

TestNet deployment is the next milestone and is expected in the next days.

CoZ-Facing Ask

The useful feedback from CoZ is in two areas.

First, on the Neo proposal:

• Is the contractHash + tokenId asset identity direction acceptable for wallets and indexers?
• Should this be a dedicated multi-fungible standard or derived from an existing Neo token standard?
• What minimal event/callback surface would CoZ expect for wallet and explorer support?

Second, on HushForge product readiness:

• Does the direct speculative-token flow make sense as the immediate Neo-compatible launchpad path?
• Is the Forge Audit Index wording clear enough that it cannot be confused with an external audit?
• Which score/trust dimensions should become indexer-backed first after TestNet deployment?

Current Decision

HushForge should continue on two tracks:

1. Ship the current Neo-compatible speculative-token flow using one NEP-17 contract per token.
2. Push the multi-fungible standard discussion so a future HushForge profile can create many fungible token identities from one deployed contract with proper wallet and indexer support.

The immediate product value is native speculative-token creation and trader-facing trust signals. The long-term Neo ecosystem value is the proposed standard that can remove repeated per-token deployment cost.