Wadoozie Info
Wadoozie is a narrative-driven, on-chain attention network built on Ethereum. A signal is being reactivated across the United States, state by state, through a live mission you can follow in real time. This is the docs hub. It explains the story behind the mission, the system that runs underneath it, the $WADZ token that coordinates everything, and the ways anyone can take part. New visitors will find the basics. Active participants will find the deeper mechanics.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is renounced
The contract does not include owner functions that allow post-deployment modifications.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The Wadoozie contract implements an ERC20 token with EIP-2612 permit support and Compound-style governance checkpoints (ERC20Votes). It is a fixed-supply, non-upgradeable, non-ownable design. All allocation happens in the constructor and there is no admin, mint, burn, pause, fee, blacklist, anti-whale or upgrade machinery anywhere on the post-deployment surface. The contract is built on OpenZeppelin v5 and the only project-written code is a four-line auto-self-delegation hook in the _update override and a one-line nonces resolver. The overall design follows common patterns on Ethereum and is internally consistent. The single point below is documented for awareness rather than as a defect:
- The launch burn is implemented as an ERC20 transfer to 0xdEaD rather than a real _burn call. This is a documented design choice disclosed in the project litepaper. As a consequence totalSupply permanently reports 2,000,000,000 WADZ and the dead address carries roughly half of the active voting power through the auto-delegation hook. The project compensates for this in the Governor configuration by setting a 3.5% quorum threshold against the reported total supply, which is mathematically equivalent to a 7% threshold against the 1,000,000,001 effective supply because totalSupply is exactly twice the effective supply, so the absolute quorum target lands where the project intends.
Ownership Privileges
The ownership of the contract has been removed by construction - the contract has no owner, no admin role, no upgrade authority, and no privileged setter of any kind. The only privilege any address has on this contract is the privilege of holding tokens. The trust boundary therefore sits at the recipient wallets selected at construction:
- The LP wallet at 0x77D9...1FeD is a Safe v1.4.1 multisig with a 3 of 5 threshold and holds 750,000,001 WADZ which is 75% of the effective supply.
- The Publisher Rewards wallet at 0x35ed...DB45 is a Safe v1.4.1 multisig with a 3 of 5 threshold and holds 70,000,000 WADZ which is 7% of the effective supply.
- The Team Vesting wallet at 0xCeec...9D0D is a Safe v1.4.1 multisig with a 3 of 5 threshold and holds 30,000,000 WADZ which is 3% of the effective supply.
- The Treasury wallet at 0xb458...AB25 is an externally owned account holding 100,000,000 WADZ which is 10% of the effective supply.
- The Signal Fragments wallet at 0xA3d6...DA42 is an externally owned account holding 50,000,000 WADZ which is 5% of the effective supply.
- The launch-burn allocation of 999,999,999 WADZ is held at 0xdEaD.
- The deployer EOA at 0xD01E...787a was drained at construction time. Its balance is and will remain zero and it has no remaining privilege of any kind on the contract.
Security Features
The contract implements several positive security features:
- The supply is fixed at construction. There is no mint function and no upgrade path that could ever introduce one. We confirmed this through symbolic execution against the totalSupply variable.
- The contract is built on a vendored copy of OpenZeppelin v5 and the standard ERC-20, ERC-2612 and ERC20Votes surfaces all conform to their specifications and to the canonical conformance tests for those standards.
- EIP-712 domain separation includes the chain id, so signed permits and delegateBySig messages cannot be replayed across chain forks.
- There is no external call in any state-changing path, no transfer callback, and no ERC-777 or ERC-1363 surface, so the contract has no reentrancy attack surface beyond the standard read-only mid-state property of any ERC20Votes implementation.
- The combined static-analysis, symbolic-execution and property-fuzzing pipeline raised no Critical, High, Medium or Low findings on the Wadoozie contract code itself.
Note - This Audit report consists of a security analysis of the Wadoozie smart contract. The launch burn pattern and the corresponding 3.5% Governor quorum calibration are disclosed by the project in its litepaper and have been verified to be internally consistent with the deployed bytecode. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Wadoozie team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
optimization Issues | 5 findings
Pending
#1 optimization Issue
Use custom errors instead of require with string messages
The constructor uses require statements with descriptive string messages for the eight pre and post conditions. Each string is encoded into the deployed bytecode and consumes more gas than an equivalent custom error.
Pending
#2 optimization Issue
Several revert strings are longer than 32 bytes
Solidity stores revert strings inline. A revert string longer than 32 bytes spills into a second storage slot in the literal pool and increases both deployment cost and revert-path cost.
Pending
#3 optimization Issue
Auto-delegation check can be expressed as a nested if to short-circuit the SLOAD
The condition 'if (from != address(0) && to != address(0) && delegates(to) == address(0))' performs three checks left-to-right. Solidity already short-circuits but the nested-if form makes the gas behaviour more predictable.
Pending
#4 optimization Issue
Constructor is not marked payable
A non-payable constructor includes a runtime check that reverts if any ETH is sent during construction. Marking the constructor payable removes that check. The contract has no native-currency logic so a payable constructor cannot trap ETH that would otherwise be lost.
Pending
#5 optimization Issue
Token allocation literals can use scientific notation
The token allocation constants use the form 2_000_000_000 ether. A scientific-notation form such as 2e27 is shorter at the source level but equivalent at compile time.
informational Issues | 9 findings
Pending
#1 informational Issue
ERC-2612 permit signatures are front-runnable on the public mempool
A signed permit can be observed on the public mempool and submitted by any address before the user's intended transferFrom is mined. If the legitimate flow later submits the same permit, the second submission reverts because the nonce has already advanced. Funds are not stolen, but the user-experience and any downstream protocol logic that relies on a successful permit can break.
Pending
#2 informational Issue
Standard ERC-20 approve race condition is unmitigated
The classic ERC-20 race - the approver wants to change the allowance from N to M, the spender front-runs and spends N, then spends M, totalling N+M - is unmitigated. The risk only materialises against a specific spender pattern and only at the moment of allowance change.
Pending
#3 informational Issue
Constructor uses string-based require which is inconsistent with OpenZeppelin v5 style
OpenZeppelin v5 uses custom errors throughout the vendored libraries. The Wadoozie constructor mixes the older require-with-string style for its eight checks. This is purely stylistic.
Pending
#4 informational Issue
Immutable variables use SCREAMING_SNAKE_CASE
The five immutable wallet addresses LP_WALLET, TREASURY, PUBLISHER_REWARDS, SIGNAL_FRAGMENTS and TEAM_VESTING are written in upper-case which is the conventional style for compile-time constants. Static analysers expect mixedCase for state variables.
Pending
#5 informational Issue
Wadoozie-defined symbols lack NatSpec documentation
The vendored OpenZeppelin code is fully NatSpec'd. The Wadoozie-specific code at the bottom of the file is not, despite being the only non-OZ logic in the contract.
Pending
#6 informational Issue
Auto-self-delegation deviates from OpenZeppelin defaults without an inline rationale
The OpenZeppelin reference implementation of ERC20Votes does not auto-delegate on inbound transfers. Wadoozie does. The deviation is intentional but not documented in the source.
Pending
#7 informational Issue
Constructor emits six DelegateChanged events at the genesis block
Each of the six recipients in the constructor (BURN_ADDRESS, lp wallet, treasury, publisher rewards, signal fragments, team vesting) is auto-self-delegated by the hook on its first inbound transfer. As a result, the deployment transaction emits six DelegateChanged events with fromDelegate equal to address(0) and toDelegate equal to the recipient itself.
Pending
#8 informational Issue
Vendored ERC721 and ERC1155 error declarations are unused
The single-file vendored OpenZeppelin bundle includes the IERC721Errors and IERC1155Errors interfaces. None of those errors is reachable from the Wadoozie contract. They were carried over from the OpenZeppelin v5 errors module and are vestigial.
Pending
#9 informational Issue
Launch burn is implemented as a transfer to 0xdEaD and inflates the governance denominator both at deployment and on every subsequent user-driven send
The constructor sends the launch-burn allocation to 0x000000000000000000000000000000000000dEaD using a plain ERC20 transfer rather than _burn. As a result totalSupply permanently reports 2,000,000,000 ether and the auto-self-delegation hook in _update assigns 999,999,999 ether of voting power to the dead address. The same accounting issue applies to every subsequent user who tries to remove tokens from circulation by sending them to 0xdEaD. Each such send leaves totalSupply unchanged and routes the moved voting units to the dead address (because BURN_ADDRESS is its own delegate from the constructor onward), which compounds the inflation over time. Any future Governor that uses getPastTotalSupply to compute quorum will measure quorum against an inflated denominator that grows monotonically with user-driven sends to dEaD. A nominal 4% quorum would be 80,000,000 votes which is 8% of the actually-castable supply at deployment, and a higher fraction over time. The same bias affects block explorers, indexers, exchange UIs and any off-chain analytics that read totalSupply to compute float, fully-diluted valuation, or quorum participation.