› AUDIT STATUS

Honest disclosure of what has and hasn't been verified

⚠ NO THIRD-PARTY AUDIT HAS BEEN COMPLETED. MINT AT YOUR OWN RISK.

What HAS been done

  • Internal test suite — 13 passing test cases covering supply invariants, mint flow, ERC-20/ERC-721 dual-path transfers, art seed regeneration, AMM pair whitelisting, full sellout simulation, owner permissions, and renderer locking. Run yourself with npx hardhat test against the public source.
  • Static analysis (planned) — Slither and Mythril scans will be run before mainnet deployment. Reports will be linked here.
  • Constructor pattern — total supply is set at construction and cannot increase. The deployer is auto-whitelisted to avoid 1500 NFT mints at construction time.
  • Public source — both contracts will be verified on Etherscan within 24 hours of deployment.

What HAS NOT been done

  • No paid third-party audit. Auditing firms like OpenZeppelin, Trail of Bits, Cyfrin, Sherlock, Code4rena, and QuillAudits have not reviewed this code. Audits cost $5K-$50K+ and we have not commissioned one before launch.
  • No formal verification. No mathematical proof of correctness using tools like Certora or KEVM.
  • No bug bounty program. We are not currently paying for responsibly-disclosed vulnerabilities.

Known risk surfaces

Areas where bugs are most likely to exist:

  • ERC404 dual-path transfer logic. The contract decides whethertransferFrom(from, to, x) is an NFT transfer or an ERC-20 transfer based on whether x is a valid token ID. Edge cases around small numeric IDs (<1500) overlapping with small token amounts could exist if not handled correctly. Our tests cover this; an auditor might find more cases.
  • Whitelist for AMM pairs. If a Uniswap V2 pair is created and the deployer forgets to call setWhitelist(pair, true) before adding liquidity, every swap will trigger NFT mints/burns to/from the pair contract — wasting gas and creating phantom NFTs. This is deployer ops risk, not a contract bug, but worth highlighting.
  • Seed entropy quality. Token seeds use keccak256(id, to, prevrandao, timestamp, blockhash). This is "good enough" for art randomness but is NOT cryptographically secure for high-stakes applications. Validators can technically influence prevrandao by 1-2 bits.
  • Re-entrancy. The mint function forwards ETH via .call(). We follow checks-effects-interactions: state writes happen before the external call. But the ERC404 burn-on-receive logic is complex enough that an auditor should verify there's no re-entrancy window.

If/when an audit is completed

If we commission a paid audit, the full report (with any findings and remediations) will be published here as a PDF. We will not paywall it. We will not redact findings.

How to audit it yourself

  1. Visit the contract page and click through to Etherscan to read the verified source.
  2. Clone the repo and run the test suite locally:git clone ... && cd glyphs && npm install && npx hardhat test
  3. Run Slither: pip install slither-analyzer && slither contracts/
  4. Verify on-chain bytecode matches the GitHub source by recompiling with the same compiler settings (0.8.24, optimizer 200 runs, viaIR, EVM cancun).