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.
Security Assessments
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 can blacklist addresses
It is 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.
Token transfer can be locked
Owner can lock user funds with owner functions.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
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 AiryAds contract implements an ERC20 token with a DEX buy and sell tax that is capped at three percent, per-transaction and per-wallet limits, an opening anti-snipe guard, a seven-day staking lock used for subscription discount tiers, on-chain linear vesting for the team and investor allocations, a referral payout function, and a forty-eight hour timelock on a subset of administrative actions. While the overall design follows common patterns on Ethereum and reuses well-known base components, a few areas need attention:
- The contract holds the vesting allocation and user staking deposits in the same balance it uses to pay referral rewards, and only the liquidity reserve is tracked separately. As written, referral payouts can spend tokens that belong to vesting beneficiaries and stakers, which can leave those obligations unbacked.
- The calculation used when revoking a vesting schedule subtracts the already released amount twice. This can cause the revoke call to fail outright once a beneficiary has claimed and more time passes, and in other cases it can leave earned but unclaimed tokens stranded in the contract.
- The per-wallet limit is also applied to sells into the liquidity pool. Because the pool normally holds more than the per-wallet limit, selling can revert under the default launch configuration, which can resemble a honeypot until the owner removes the limits. There is no setting that keeps the tax, the limits and working sells at the same time, so this needs attention before any listing.
- If the owner pauses the contract and then completes the ownership renouncement, no one is left who can lift the pause, and the token would stay frozen permanently. Renouncement should not be possible while the contract is paused.
Ownership Privileges
The ownership of the contract has not been renounced and is held by a single owner account that uses a two-step transfer mechanism. The owner retains full privileges including:
- Pausing and unpausing all token transfers at any time, which also blocks staking withdrawals and vesting claims, and which would become permanent if ownership were renounced while paused.
- Adding or removing any address from a blacklist that blocks both sending and receiving.
- Moving the contract-held balance through the referral payout and liquidity withdrawal functions.
- Adjusting the buy and sell taxes within the three percent cap and behind a forty-eight hour delay, along with transfer limits, exclusions and liquidity pair designations.
- There is no function to create new tokens after deployment, so the supply is fixed at one hundred million.
- The buy and sell taxes can never exceed three percent.
- The contract's own token cannot be withdrawn through the accidental-asset recovery function.
- Ownership renouncement is irreversible and is itself subject to a forty-eight hour delay that can be cancelled before it completes.
Security Features
The contract implements several positive security features:
- It is built on widely used and audited base components for the token, signed approvals, ownership and pause logic.
- Reentrancy protection is applied to the functions that move tokens or value, and the transfer path contains no external token callbacks.
- Ownership uses a two-step transfer, and renouncement follows a delayed and cancellable flow rather than an instant action.
- Tax and marketing wallet changes pass through a forty-eight hour timelock, and the maximum supply is fixed and enforced at deployment.
Note - This Audit report consists of a security analysis of the AiryAds smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the AiryAds 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
Findings and Audit result
high Issues | 2 findings
Pending
#1 high Issue
Pooled contract balance lets referral payouts spend staking and vesting tokens
The contract keeps three separate pools of token balance in one place: the twenty five million tokens locked for team and investor vesting, the tokens users deposit when they stake, and the tax funded liquidity reserve. Only the liquidity reserve is tracked by a counter. The referral payout function treats everything except the liquidity reserve as spendable, computing the available amount as the contract balance minus the liquidity reserve. Because that figure still includes staked and vesting tokens, and no allocation actually funds a referral pool, paying referrals necessarily spends tokens that are owed to stakers and vesting beneficiaries. Once those tokens leave, claiming vested tokens and unstaking revert for lack of balance, so beneficiaries and stakers permanently lose access to their funds. A compromised owner key can drain all contract held tokens this way.
Pending
#2 high Issue
Per-wallet limit blocks sells into the liquidity pair
The per-wallet cap is checked on every transfer that does not involve an excluded address, including sells where the recipient is the liquidity pair. For the buy and sell tax to apply, the pair must not be excluded, because exclusion turns off both tax and limits. Once liquidity is added, the pair holds far more than the per-wallet cap, so every later sell from a normal holder fails the check that the recipient balance plus the incoming amount must stay under the cap, and the sell reverts. This is the default launch configuration, and there is no setting that keeps the tax, the limits and working sells at the same time, since excluding the pair disables the tax and only removing the limits restores selling. As a result holders can buy but cannot sell, which looks like a honeypot and traps buyers until the owner intervenes.
medium Issues | 3 findings
Pending
#1 medium Issue
Vesting revocation formula underflows and strands tokens
When the owner revokes a vesting schedule the contract should return only the portion that has not vested yet, which is the total minus the vested amount. Instead it subtracts the released amount a second time, computing total minus vested minus released. Since the vested figure already includes whatever was released, this is wrong in two ways. When vested plus released is greater than the total, which happens after the beneficiary has claimed and more time passes, the subtraction underflows and the call reverts, so the schedule can no longer be revoked and the unvested remainder can never be recovered. When it does not underflow, the owner receives less than the unvested amount, and because the schedule is now marked revoked the beneficiary can no longer claim, so the earned but unclaimed tokens are stranded in the contract.
Pending
#2 medium Issue
Creating a vesting schedule silently overwrites an existing one
Creating a vesting schedule assigns the schedule to the beneficiary unconditionally, with no check that one does not already exist. Calling the create function twice for the same beneficiary overwrites the first schedule, resets the released counter to zero and replaces the total, while the tokens that were transferred in for the first schedule stay in the contract without being tracked. The beneficiary loses the original schedule, the stranded tokens add to the unaccounted balance, and because released resets to zero a beneficiary who had already claimed could claim again against the new schedule.
Pending
#3 medium Issue
Pausing then renouncing ownership freezes the token permanently
The owner can pause all transfers and then complete ownership renouncement, which sets the owner to the zero address. Because the unpause function is restricted to the owner and the transfer hook blocks every movement while paused, once ownership is gone there is no one left who can unpause. The token would then be permanently frozen, with all transfers, staking withdrawals and vesting claims reverting forever. This can happen through a deliberate sequence or simply by renouncing while the contract is paused, since nothing prevents it. It is more severe than an ordinary pause because the state is irreversible and affects every holder.
low Issues | 7 findings
Pending
#1 low Issue
Documentation overstates timelock coverage
The contract documentation states that all privileged parameter changes are subject to a forty-eight hour timelock. In practice only the buy tax, the sell tax, the marketing wallet and ownership renouncement go through the timelock. Blacklisting, exclusion, the per-wallet and per-transaction limits, the tax split, the liquidity pair designation, the referral settings, pausing, limit removal, referral payouts, liquidity withdrawal and vesting creation and revocation all take effect immediately. In particular blacklisting and pausing are instant and can freeze any holder without notice.
Pending
#2 low Issue
Anti-snipe window can be prolonged by repeated extension
The anti-snipe guard blocks buys from the liquidity pair to non-excluded addresses during an opening window. The extend function caps each extension to ten blocks ahead of the current block, but it can be called again every few blocks while the guard is still active, repeatedly pushing the window forward. This lets the owner keep buys blocked well beyond the short window described in the documentation, while sells remain possible.
Pending
#3 low Issue
Unstaking is blocked while the contract is paused
The unstake function does not carry the not-paused guard, which suggests users are meant to be able to withdraw staked tokens during a pause. However the internal transfer it performs goes through the update hook, which does carry the not-paused guard, so while the contract is paused stakers cannot withdraw even after their seven day lock has elapsed, and vesting claims are blocked as well. There is no maximum pause duration, so the owner can keep staked and vesting funds frozen indefinitely.
Pending
#4 low Issue
Blacklisting freezes a holder's own staked and vested tokens
The blacklist check in the transfer hook blocks both sending and receiving. A blacklisted holder therefore cannot unstake or claim vested tokens, because the transfer from the contract to that holder reverts, so the holder's own principal is frozen. Blacklisting the liquidity pair stops all trading. This is inherent to address blacklists but represents a meaningful centralization power that should be stated plainly.
Pending
#5 low Issue
Referral payout ignores the configured cap and referrer link
The referral configuration includes a reward rate in basis points that is capped at ten percent and a flag for whether the program is live, but the payout function does not read either value. It transfers an arbitrary owner-chosen amount to an arbitrary address. The mapping that records who referred whom is written when a user sets a referrer but is never read on chain. As a result the on-chain referral controls give no real guarantee about reward sizes or recipients.
Pending
#6 low Issue
Liquidity pair accepts arbitrary addresses and wallet execute lacks re-validation
The function that registers liquidity pairs accepts any address, including a normal user wallet, and flags it as a pair, which changes how transfers to and from it are taxed and limit checked. Separately, the function that executes a queued marketing wallet change does not re-check that the new wallet is non-zero. It is safe only because the queueing step rejects the zero address and the operation identifier binds the address, so the protection is implicit rather than defensive.
Pending
#7 low Issue
Anti-snipe guard is tied to the deployment block, not to trading activation
The anti-snipe guard window is fixed at deployment as the current block plus a small number of blocks. In a normal launch the liquidity pool and pair are set up some time after deployment, by which point the window has already elapsed, so the guard does nothing when trading actually begins. The extend function only works while the guard is still active, so once it has expired it cannot be re-armed. As a result the anti-snipe protection is generally ineffective for any listing that does not happen within seconds of deployment.
optimization Issues | 5 findings
Pending
#1 optimization Issue
Tax math divides before multiplying
The tax calculation divides to get the tax amount and then multiplies that result by the marketing percentage before dividing again. The rounding always favors the contract by at most one unit so it is safe, but doing the multiplication before the final division in a single expression would avoid a second truncation and is slightly cleaner.
Pending
#2 optimization Issue
Airdrop loop can be optimized
The airdrop loop reads the array length on each iteration and increments the counter with checked arithmetic. Caching the length and incrementing in an unchecked block saves gas across large batches. Note also that a single invalid entry reverts the whole batch, which is acceptable for an owner only airdrop but should be understood.
Pending
#3 optimization Issue
Structs can be packed into fewer storage slots
The tax configuration stores three full word values even though the buy and sell rates never exceed three hundred and the marketing percentage never exceeds one hundred, so they would fit in much smaller types. The vesting structure stores two booleans alongside several timestamps and could also be packed. Packing these would reduce the number of storage slots used.
Pending
#4 optimization Issue
Timelock identifier hashing can use a tighter encoding
The timelock operation identifiers are built with a hash over an encoding of the operation label, the value and the timestamp. This is correct and safe. A tighter encoding for the hash input would save a small amount of gas.
Pending
#5 optimization Issue
Threshold numbers should be named constants
The maximum referral rate of one thousand basis points and the divisors used to derive the wallet and transaction limit floors appear as bare numbers. Naming them as constants makes the intended bounds explicit and prevents accidental drift if they are referenced in more than one place.
informational Issues | 10 findings
Pending
#1 informational Issue
Anti-snipe event is emitted right before a revert and never persists
Inside the transfer hook the anti-snipe branch emits an event reporting that the guard was triggered and then immediately reverts the transaction. Because a revert rolls back all state changes including emitted events, this event is never actually recorded on chain, so off chain systems that watch for it will never see it.
Pending
#2 informational Issue
Referrer mapping is written but never read on chain
The mapping that records which address referred a given user is written when a user registers a referrer but is never read anywhere in the contract. It only carries meaning for off chain systems.
Pending
#3 informational Issue
Parameter naming does not follow the common convention
Function parameters use a leading underscore naming style that does not match the usual mixed case convention for parameters. This is purely stylistic and is applied consistently across the contract.
Pending
#4 informational Issue
Marketing wallet events do not index their address parameters
The events that announce a queued marketing wallet change and an executed marketing wallet change carry address values that are not marked as indexed. Indexed address parameters make it much easier for off chain tools to filter logs by address.
Pending
#5 informational Issue
Magic numbers used in arithmetic
Several constants appear as bare numbers in the code, such as the ten thousand basis point denominator, the one hundred used for percentage math and the divisors used to derive the limit floors. Bare numbers make the intent less clear and are easier to get wrong during maintenance.
Pending
#6 informational Issue
Revert strings used instead of custom errors in one function
The function that extends the anti-snipe guard uses revert strings for its two checks, while the rest of the contract uses custom errors. Mixing the two styles is inconsistent and revert strings cost slightly more gas.
Pending
#7 informational Issue
Anti-snipe active window is off by one block versus the documentation
The anti-snipe guard uses a less than or equal comparison against the guard block, so it is active for four blocks counting from deployment rather than the three blocks described in the documentation. The effect is minor but the comment and behavior do not match.
Pending
#8 informational Issue
Standard approval race condition
The token uses the standard approval mechanism, which carries the well known race condition where a spender can use both an old and a new allowance if approvals are changed without first setting the allowance to zero. The token also provides signed approvals through the permit extension, which mitigates the issue for users who use it.
Pending
#9 informational Issue
Reentrancy guard is not the first modifier
On several functions the reentrancy guard is not the first modifier in the list. The behavior here is fine, but listing the reentrancy guard first is the generally recommended ordering so that the guard is established before other checks run.
Pending
#10 informational Issue
Floating compiler pragma
The source uses a floating compiler version of caret zero point eight point twenty four, which lets it compile with any later zero point eight release. Different compiler versions can produce different bytecode and target a different virtual machine version, so the deployed code may not match the version that was reviewed. This is treated as informational unless the deployment pipeline actually compiles with varying compiler versions.