Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Boxa Info

boxa.club

BOXA is a launchpad and trading site on Elysium. Elysium is a chain that settles to HyperEVM.

Boxa Logo
Onboarded date 05/11/2026

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.

74.49
Poor Excellent

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

Select the audit
Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review
Contract address
N/A
Network N/A
License GPL-3.0-or-later
Compiler ^0.8.26
Type Uniswap v4 Hook
Language Solidity
Onboard date 2026/11/05
Revision date 2026/11/05

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 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:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. 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 BoxaUniHookV2 contract implements a Uniswap v4 hook that serves every BOXA launch pool on Elysium. It takes a fee of 1% plus an optional creator-defined extra of up to 9% on the quote side of each swap, splits it between the BOXA treasury, the pool creator, the token holders and a buyback-and-burn queue, and pays everyone out through pull-based claims held inside the PoolManager. Holder shares now wait until they are released outside of any trade, and buybacks are limited by a price reference that the hook keeps on chain. The launch liquidity stays locked forever and donations are refused. This re-audit covers version 2 of the contracts at commit d1d5a98, which had not been deployed at the time of the review. The contract cannot be upgraded.

Ownership Privileges

The ownership of the contract will be held by the address chosen at deployment. Because version 2 is not deployed yet, we could not verify whether that address will be a multisig, and the code itself contains no timelock. The owner retains full privileges including:

  • Setting the treasury's share of the creators' extra tax, between 0% and 10% of that tax, for pools launched from then on.
  • Allowing or removing ERC-20 tokens as quote assets for new launches and choosing their opening price, after a test transfer and a supply check.
  • Moving the treasury to a new address in two steps, in which case the treasury's unclaimed credit moves with it.
  • Handing ownership to a new address through a two-step process, or renouncing it, which freezes the settings and the treasury.
  • The owner cannot change the fees, shares or any other terms of a pool once it has launched, and creators can refuse settings that changed just before their launch.
  • The owner cannot add, move or remove liquidity, and nobody can ever remove the launch liquidity.
  • The owner cannot touch any creator credit, holder reward or buyback budget, and cannot pause, mint, blacklist or upgrade anything.
  • Buybacks can be started by anyone and are limited on chain; neither the owner nor the treasury has any special power over them.

Security Features

The contract implements several positive security features:

  • Holder rewards are only shared out while the PoolManager is locked and never in a transaction in which the token moved, so borrowed or briefly held tokens earn nothing.
  • Each buyback may only buy up to about 2% above a reference price that cannot be moved within a second and rises slowly; what it cannot spend stays queued.
  • Buys that do not fill completely revert, so the fee never exceeds the advertised maximum of 10% of what is swapped; fees are capped, frozen at launch and always split in full.
  • Launch liquidity is permanently locked, donations are refused, payouts are pull-based per currency and protected by a reentrancy guard, and the zero address is refused as a recipient.

Auditor's Comments

All issues of the previous version that could be fixed in code have been addressed. The capture of holder rewards with borrowed tokens, the sandwiching of the buyback, the anti-snipe limit that could be bypassed, which has been removed, and the fee charged on unfilled buys are resolved, and we confirmed each fix by repeating the original attacks. One new low-severity point remains: the price reference follows rises at one tick per second, so a party that raises the price and keeps it there long enough, about two hours for a doubling in our test, can still make the buyback buy at the raised price and then sell into it. This requires a large queued budget and nobody trading against the raised price in the meantime. Holder rewards are now only paid out when someone calls the release or claim function, so the team should run a keeper. The owner can now redirect the treasury together with its unclaimed credit, and should therefore be a multisig behind a timelock. The compiler version should be fixed and the build settings published before deployment.

Note - This Audit report consists of a security analysis of the BoxaUniHookV2 smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the BOXA team; the BOXA launch token and the launcher are covered by their own statements. Other contracts associated with the project, such as the Uniswap v4 PoolManager and the quote tokens, were not audited by our team. We recommend investors do their own research before investing.

Files and details

Findings and Audit result

Critical
High
Medium
3
Low
Optimization
2
Informational
high Issues | 1 findings

Resolved

#1 high Issue
Holder rewards can be captured with tokens borrowed from the PoolManager inside a single transaction
BoxaUniHookV2.sol
L329-332
L632-647
L681-689
L696-709
L766-787
Description

Holder rewards are split by the token balances that exist at the moment of distribution, and the PoolManager is excluded from earning. Inside a Uniswap v4 unlock, any contract can take the pool's own token reserves at no cost as long as it returns them before the unlock ends. While it holds them it owns almost the whole earning supply, so calling releaseHolderRewards, or any swap, hands it nearly the entire pending holder share, and the credit stays after the tokens are returned. The same works for the holder share of a buyer's own buy, and for a seller who releases the pending share before settling. We reproduced this on the live deployment: one transaction collected 99.7 percent of the pending holder rewards of every live pool that had any. On pools without real holders it collected everything that would otherwise have gone to buyback.

Comments

Stop distributing holder rewards while the PoolManager is unlocked, because that is the only state in which such borrowed balances can exist. Accrue every holder share, buys and sells alike, to the pending balance, and release it only through entry points that check the PoolManager is locked, for example with TransientStateLibrary.isUnlocked. Remove the release from beforeSwap. The hook cannot be upgraded, so the fix has to ship with a new hook and launcher. Until then, the official frontend should call releaseHolderRewards right after each sell, outside the unlock, and holders should be told that large traders can avoid the holder part of the buy tax.

Alleviation

Resolved in V2. Every holder share of buys and sells now waits as pending, swaps no longer hand anything out, and releaseHolderRewards and claimRewards revert while the PoolManager is unlocked. In addition, the token refuses to share out rewards in any transaction in which an earning balance has moved, so tokens borrowed from any venue, or bought and sold within one transaction, earn nothing. We re-ran the original attacks against V2: the flash loan from the PoolManager and the release by a seller before settling now revert, a buyer holding a loan is paid only for the tokens it really holds at a later release, and a flash loan from another venue while the PoolManager is locked leaves the share pending. Rewards are now handed out only when someone calls the release or claim function, and a holder that buys before a release and sells after it still receives its pro-rata part, including part of the holder share of its own buy, at the cost of two trading fees. The team should run a keeper, or have its frontend call releaseHolderRewards regularly, so that pending amounts stay small.

medium Issues | 3 findings

Resolved

#1 medium Issue
Buyback swap has no on-chain price bound and can be sandwiched by the party that triggers it
BoxaUniHookV2.sol
L69-72
L119-123
L642
L715-741
L796-812
Description

processBuyback spends the whole queued budget in one swap with the price limit set to the far end of the curve, so the only protection is the minimum output chosen by the caller, and the caller is always the pool creator or the treasury. A creator that controls a contract can buy first, run the buyback with a minimum of zero at the inflated price and sell back in the same transaction, while also earning 70 percent of the base fee on its own trades. The treasury, a single externally owned account, has the same power over every pool. In our test the creator kept 3.6 HYPE of a 6.4 HYPE budget, and the buyback burned 28 million tokens instead of 96 million.

Comments

Bound the buyback price on chain against a reference the caller cannot move in the same transaction, such as a time-weighted price kept by the hook, and cap each execution to a small deviation from it while leaving the rest queued. Executing buybacks in small slices during ordinary trades, or making the trigger permissionless under that on-chain bound, removes the incentive for one party to time them. Until a new version exists, the treasury should only trigger buybacks in small amounts with a tight minimum output.

Alleviation

Resolved in V2. The buyback is now bounded by a price reference kept by the hook. The reference is updated at most once per second from the price before any trade of that second, follows the price down at once, rises by at most one tick per second and never falls below the opening price. A buyback may only push the price 200 ticks, about 2 percent, above the reference, and whatever it cannot spend stays queued. The trigger is now open to anyone, and the treasury no longer has a special role. In our tests the original sandwich within one transaction now reverts, and every pump small enough to stay inside the bound left the attacker with a loss, even when it was the creator. A slower attack that holds a raised price for a long time remains and is reported as a separate finding.

Resolved

#2 medium Issue
Anti-snipe limit is checked per swap and can be bypassed by batching swaps
BoxaUniHookV2.sol
L466-489
L650-669
Description

During the first 60 seconds of an anti-snipe pool, afterSwap only rejects a single swap that returns more than 10 million tokens. A Uniswap v4 unlock can contain any number of swaps, so one transaction can make many swaps just below the cap, and there is no limit per transaction, block or buyer. In our test one transaction at the launch second bought 140 million tokens, fourteen times the cap, while a single large buy was correctly refused. 118 of the 310 live pools rely on this protection.

Comments

Enforce the cap on a cumulative amount during the window, for example the total bought per pool per second or per layer-2 block, or replace it with a sniper fee or cap that declines over the window. Counting per transaction in transient storage is the minimum improvement but does not stop several transactions in one block. On Arbitrum Orbit chains block.number follows the parent chain, so use timestamps or the ArbSys block number for the buckets.

Alleviation

Resolved by removing the feature. V2 no longer offers an anti-snipe option, so no pool advertises a limit that cannot be enforced. As a consequence, launches have no protection against large early buys apart from the creator's own first buy in the launch transaction, and the frontend should not describe any pool as protected against snipers.

Resolved

#3 medium Issue
Buy fee is charged on the full requested input even if the swap fills only partly
BoxaUniHookV2.sol
L657-664
Description

The buy fee is computed in beforeSwap from the requested input. If the swap then stops early at the caller's price limit, the unused input is returned, but the fee on it is still charged and is lost to the buyer. In our test a 10 HYPE buy with a tight limit swapped about 0.03 HYPE and paid a 1 HYPE fee, an effective rate of 97 percent against the advertised 10 percent maximum. A pool creator, who earns part of every fee, can also push the price just before such a buy so that it fills only a fraction. Users of the standard router are not affected because it never sets a price limit, and a sufficient minimum output makes such a trade revert instead.

Comments

Reject partial fills on the buy side in afterSwap by checking that the consumed input plus the fee equals the requested amount. The fee itself cannot be moved to afterSwap and charged on the consumed quote, because in Uniswap v4 an afterSwap delta can only be taken in the other currency, which for a buy is the BOXA token; charging buy fees in BOXA would change the fee model. Until a fixed version exists, integrators and the frontend should not pass a price limit on buys and should rely on a minimum output instead.

Alleviation

Resolved in V2. afterSwap now recomputes the buy fee and reverts unless the swap consumed the whole input after the fee, so a buy that stops at a price limit or at the end of the curve no longer pays a fee on input it never used. We confirmed that the original 10 HYPE buy with a tight price limit now reverts without keeping any fee, and that a fully filled buy always pays exactly the rounded-up rate. Sells may still stop at a price limit, which is safe because their fee is taken from the output actually received. Integrators that pass their own price limit on buys will now see reverts instead of overcharges.

low Issues | 3 findings

Acknowledged

#1 low Issue
Quote asset allowlist includes reward-bearing and upgradeable tokens
BoxaUniHookV2.sol
L84-89
L381-403
Description

The hook's documentation limits quote assets to plain ERC-20 tokens, but the owner has allowlisted BOXA and ELYCAT from the earlier BOXA v4 deployment. Their reward bookkeeping excludes a different PoolManager, so the current PoolManager earns their holder rewards on everything it holds for the four live BOXA-quoted pools. Those rewards can never be claimed, which dilutes the real holders of those tokens. KNTQ and wNVDAx are bridge tokens behind an upgradeable beacon whose behaviour can change after allowlisting, and the launcher's check against short deliveries only runs when a launch includes a first buy.

Comments

Only allowlist plain, non-upgradeable ERC-20 tokens and stop offering BOXA and ELYCAT for new launches; existing pools keep working. Document who can upgrade the bridged quote tokens. In a future version, test a transfer when a quote asset is allowlisted and make BOXA-style quote tokens exclude the current PoolManager.

Alleviation

Partly addressed. When a quote asset is allowed, V2 now makes a test transfer from the owner and back and refuses assets whose transfer moves a different amount or whose supply exceeds 1e30 raw units, and the documentation restricts the allowlist to plain, non-upgradeable tokens without transfer hooks. These checks catch transfer fees at the time of listing, but they cannot detect reward-bearing tokens such as the earlier BOXA and ELYCAT tokens, upgradeable bridge tokens, or later changes in a token's behaviour, so the choice of assets remains the owner's responsibility. At the time of the re-audit the live V1 hook still allowed BOXA and ELYCAT for new launches.

Acknowledged

#2 low Issue
Owner and treasury are single externally owned accounts without a timelock
BoxaUniHookV2.sol
L132-139
L375-443
Description

The owner, an externally owned account, can change the treasury's cut of future extra taxes, the quote asset allowlist and its opening prices with immediate effect. The treasury is an immutable externally owned account that receives 30 percent of every base fee plus its cut of the extra tax, and it may trigger the buyback of every pool with its own slippage setting. A compromised treasury key could therefore drain buyback budgets across all pools, and a lost key would lock its credit for good because the address cannot be changed.

Comments

Move ownership to a multisig such as a Safe with at least two of three signers, and put settings changes behind a timelock. In the next version make the treasury a multisig that can be rotated through the timelock, and either remove its buyback trigger or subject it to the on-chain price bound recommended for the buyback.

Alleviation

Partly addressed. The treasury can now be rotated in two steps and its unclaimed credit moves with it, so a lost treasury key no longer loses that credit, and the treasury no longer has any special power over buybacks, which anyone can now trigger under the on-chain price bound. The owner is still a single address that changes settings with immediate effect, there is no timelock in the code, and because V2 is not deployed yet we could not verify that ownership will sit with a multisig. The rotation also lets the owner move the treasury, together with its unclaimed credit, to any address that accepts it, so the owner key now controls BOXA's own fee revenue. Creator credits, holder rewards and buyback budgets remain out of the owner's reach. Ownership should be given to a multisig behind a timelock before V2 goes live.

Pending

#3 low Issue
Buyback price bound can be met by holding a raised price until the reference catches up
BoxaUniHookV2.sol
L69-72
L715-741
L796-812
Description

The buyback reference follows the pool price upward by one tick per second, so after any price rise the bound catches up after as many seconds as the rise has ticks. Anyone who pushes the price up and keeps it there long enough can therefore make the buyback spend its budget at the raised price and then sell into it. In our test a party with no special role bought 25 HYPE of tokens, which doubled the price, held the position for about 110 minutes with nobody trading against it, let the buyback run and sold, and ended 2.29 HYPE ahead on a budget of 6.42 HYPE. As the creator, which gets part of the fees back, it ended 2.66 HYPE ahead. The attack needs a large queued budget and carries real market risk, because any holder can sell into the raised price while it is held.

Comments

Make the reference follow rises more slowly, for example by one tick every ten seconds, or base it on a longer time-weighted average, and consider limiting how much of the queue one execution may spend. Triggering buybacks regularly, for example from a keeper, keeps the queue small and limits what such an attack can win. Document that the bound protects against short-lived manipulation only.

optimization Issues | 3 findings

Resolved

#1 optimization Issue
Pool struct can be packed into four storage slots
BoxaUniHookV2.sol
L91-105
Description

The Pool struct uses five storage slots because the small fields do not fill the free space next to the addresses, and every swap reads fields from all five. Reordering the fields fits the struct into four slots and the fields used during swaps into three.

Comments

Place the basis point fields and the buy tax next to token, the sell tax, launch time and anti-snipe flag next to quote, and quoteIs0 next to creator. This saves a cold storage write per launch and about two cold storage reads per swap. Because it changes the getter's tuple order, it belongs in the next version.

Alleviation

Resolved in V2. The Pool struct now fits in four storage slots, and the pools getter keeps the previous field order apart from the removed anti-snipe flag.

Resolved

#2 optimization Issue
Reentrancy guard can use transient storage
BoxaUniHookV2.sol
L315-326
Description

The guard is a storage variable that is written twice on every claim, reward claim, release and buyback. The chain supports transient storage, which the PoolManager already relies on.

Comments

Use a transient storage guard such as ReentrancyGuardTransient to save a few thousand gas per guarded call.

Alleviation

Resolved in V2. The reentrancy guard now uses transient storage.

Resolved

#3 optimization Issue
Fee split subtractions can be unchecked
BoxaFeeSplitV2.sol
L41-50
Description

The subtractions in BoxaFeeSplit.split can never underflow, because each share subtracted is bounded by the value it is taken from, and the products are bounded by the amount times 100,000.

Comments

Wrap these subtractions in an unchecked block to save gas on every swap, keeping the existing tests as a safeguard.

Alleviation

Resolved in V2. The subtractions now run in an unchecked block. We proved again that the fee is always split in full for every allowed input, and confirmed by review and by fuzzing that no part can exceed the fee, which rules out a silent wrap. The unchecked block relies on the hook validating the cut and the shares before every call, which it does for pools and for previews.

informational Issues | 7 findings

Resolved

#1 informational Issue
Allowed opening tick range contains values for which every launch reverts
BoxaUniHookV2.sol
L79-83
L390-392
Description

setQuoteAsset accepts opening ticks down to -400,000. Below -349,200, however, the single-sided launch position needs more liquidity per tick than Uniswap v4 allows, so every launch against such a quote asset would revert. No funds are at risk, but a misconfigured quote asset would be unusable.

Comments

Raise MIN_START_TICK to -349,200, or check the resulting liquidity against the per-tick maximum when a quote asset is set.

Alleviation

Resolved in V2. The lowest accepted opening tick is now -349,200. We confirmed that launches at both ends of the accepted range succeed for both token orderings and that a tick of -349,400 is refused.

Resolved

#2 informational Issue
Missing and misleading events around holder shares and buybacks
BoxaUniHookV2.sol
L184
L191-202
L219
L596
L681-690
L700-708
Description

FeeTaken always reports the holders' credit, even when that share is later sent to buyback because almost nobody holds the token, or is only pending after a sell. The redirect to buyback emits no event at all, so off-chain accounting cannot follow where the holder share went. The launch time is stored without an event, and the buyback event names its amount nativeSpent even for ERC-20 quotes.

Comments

Emit a dedicated event when a holder share is redirected to buyback and when a pending share is released, and give amount fields neutral names such as quoteSpent in the next version.

Alleviation

Resolved in V2. HolderRewardsRedirected is emitted whenever a holder share goes to buyback, HolderRewardsAdded marks every release, PoolLaunchTime records the launch, the buyback event field is now called quoteSpent, and the documentation of FeeTaken explains that the holder share is pending or redirected. The token also emits its own events for distributions and withdrawals.

Resolved

#3 informational Issue
Payout functions accept the zero address as recipient
BoxaUniHookV2.sol
L265
L748-749
L766-767
Description

claim and claimRewards send the payout to any recipient, including the zero address. For native HYPE that transfer succeeds, so a mistaken call permanently burns the caller's credit.

Comments

Revert when the recipient is the zero address.

Alleviation

Resolved in V2. claim and claimRewards now revert with InvalidRecipient when the recipient is the zero address.

Resolved

#4 informational Issue
Misleading errors, duplicated constants and incomplete NatSpec
BoxaUniHookV2.sol
L19
L67-76
L96
L263
L279
L338-340
L801
Description

The constructor reports zero addresses as InvalidPool, and an empty buyback queue reverts with NothingToClaim. BPS, DEAD and TICK_SPACING are declared again in several contracts, although the hook and the launcher must agree on them. The Pool struct field extraCutBps shares its name with a state variable, and most external functions lack parameter and return documentation.

Comments

Use dedicated errors, import shared constants from a single place, rename the struct field and complete the NatSpec in the next version.

Alleviation

Resolved in V2. The constructor reverts with ZeroAddress, an empty buyback queue reverts with NoBuybackBudget, the supply, dead address and tick spacing now come from one constants file shared by the hook, launcher and token, the struct field is renamed fixedExtraCutBps, and the external functions now document their parameters and return values. A few smaller points in the new code are reported separately.

Resolved

#5 informational Issue
Dependence on the PoolManager owner and donations lost to the locked position
BoxaUniHookV2.sol
L271
L362
L622-629
Description

The owner of the PoolManager, an externally owned account, can appoint a protocol fee controller that may charge up to 0.1 percent per swap on these pools, which traders would pay on top of the hook's fee. Donations to a BOXA pool are allowed because beforeDonate is not used. They accrue to the permanently locked launch position, so they are lost to the donor.

Comments

Disclose the protocol fee dependency to users, and consider enabling beforeDonate to reject donations in the next version.

Alleviation

Resolved in V2 as far as the code allows. beforeDonate is now enabled and always reverts, so donations can no longer be lost to the locked position. The protocol fee that the PoolManager owner may switch on remains an external dependency by nature and should be disclosed to users.

Pending

#6 informational Issue
Compiler with known bugs and unverified deployed code
BoxaUniHookV2.sol
L2
Description

Solidity 0.8.26 has several known compiler bugs. We checked their conditions and none apply to this code, although the optimizer bookkeeping issue cannot be excluded by inspection alone. The deployed code carries no source metadata hash and the source is not verified on the block explorer, so users cannot independently confirm what was deployed. We reproduced the deployed bytecode exactly from the audited source with the matching dependency versions.

Comments

Publish the exact build configuration and dependency commits next to the source, verify the contracts on the explorer when possible, and use a current compiler for the next deployment.

Alleviation

Not resolved. The V2 files now use the floating pragma ^0.8.26, so the code no longer fixes the compiler that will build the deployment, and every release from 0.8.26 to 0.8.37 has known bugs. As far as we could check, none of their conditions apply to this code. The build configuration and the dependency versions, including the OpenZeppelin release, were not published with the V2 sources, and the contracts are not deployed yet, so explorer verification could not be checked. The pragma should be fixed to the exact compiler used for the deployment, preferably 0.8.38, which has no known bugs, the build settings and dependency commits should be published next to the sources, and the deployed contracts should be verified.

Pending

#7 informational Issue
Raw transient storage slot, future keyword and missing treasury event
BoxaUniHookV2.sol
L121
L315-326
L338-347
L528
Description

The reentrancy guard writes transient storage slot 0 directly in inline assembly. Solidity places transient state variables from slot 0 onwards, so a transient variable added in a later version would silently share the guard's slot. The PriceReference field named at compiles today, but current compilers already warn that at will become a reserved keyword, which would stop the code from compiling unchanged. The constructor emits no event for the first treasury, although the treasury can now change, and claimable is declared public although it is only called from outside.

Comments

Use a hashed transient slot, as OpenZeppelin's ReentrancyGuardTransient does, rename the at field, emit TreasuryTransferred from the zero address in the constructor, and declare claimable external.