Memecoin staking had owner controls and a separate upgrade role in its 2024 audit

Staking MEME depended on shared contract settings

In the reviewed design, staking and unstaking used a shared contract configuration check. The stake , stakeFor , and unstake functions each carried onlyValidStakingSetup and nonReentrant , a guard against reentrant calls. Configuration checks and reentrancy protection addressed different concerns within the same operations. The owner could change the staking activation setting and start date.

Which settings could the owner change?

The audited owner could change shared settings for staking activity, the staking start date, and the assignment of upgrade authority.

Activation and start timing

The functions setStakingActive and setStakingStartDate both required onlyOwner . Ordinary access to staking did not grant permission to change either setting. The owner could adjust these settings after initialization. The report gave access rules without establishing whether staking was active or which start timestamp a later deployment used.

Assigning upgrade authority

The report also listed renounceUpgrader among owner-only functions. A function allowing changes to an upgrade role does not establish that administrators exercised it.

How did the upgrader change the staking contract?

Under the audited UUPS upgrade design, the designated upgrader could replace the contract implementation. The internal _authorizeUpgrade function required onlyUpgrader , identifying the role controlling that change. This power reached beyond adjusting an activation setting or start date. An implementation upgrade could change the logic containing those rules, which explains its place within the authority finding.

A review of one implementation cannot establish the security of replacement logic introduced later. The final audit commit anchored the findings to a particular source revision; later changes could alter behavior or permissions. The upgrade mechanism therefore made the version in use relevant throughout the system’s maintenance, including after developers addressed the original suggestions.

The medium finding remained acknowledged

The final audit recorded the excessive-authority finding as medium severity with an acknowledged status. The audit ran from 30 January to 2 February 2024. Its authority finding covered the owner’s parameter controls and the upgrader’s ability to change the implementation. An acknowledged status recorded recognition of the issue without reporting its remediation.

The three fixed suggestions addressed different issues. Their completion did not change the authority finding’s recorded status or erase the underlying administrative capabilities.

Fixed suggestions addressed checks and code clarity

The report marked its return-value, redundant-code, and zero-address suggestions fixed. Each entry concerned a particular implementation detail rather than removing the administrative roles.

Token approvals and reward proofs

The reviewed MultiClaim constructor called the token’s approve function without checking its return value. Within the staking contract, _redeemRewards and stakeOf also called _verifyProof without checking its result. A function returning a failure value differs from execution stopping with an error. Calling code needs to handle that result for the check to govern subsequent logic. The report recommended checking these returned values and marked the suggestion fixed. This addressed how the implementation handled results from other functions, a separate concern from privileged access.

Initialization and unused variables

The report marked the missing zero-address check for the initializer’s _delegate parameter fixed. That input identified the delegate dependency supplied during initialization. The shown code already checked the token address, which did not substitute for validating the delegate address.

The redundant-code entry discussed unused name , symbol , and decimals variables in the staking contract. The final note marked the suggestion fixed and explained that the updated version supplied clear context for the previously unclear code.

Did multisig administration remove the upgrade risk?

A multisig could distribute signing authority without eliminating the contract’s privileged powers. SlowMist recommended multisig ownership as a short-term response to single-point risk. For longer-term administration, it proposed separating privileges across roles.

Stakeland’s published About description lists multisig wallets for Delegate and Staking administration. Its approval model requires a configured number of approvals from its signer set, without specifying a numeric threshold. A multisig holding upgrade permission can still authorize an implementation change; distributed signing and restricted capabilities address different aspects of control.

Project rewards follow separate release conditions

At the audit stage, the report stated that the reviewed code had not reached mainnet deployment. That historical environment does not establish that staking never launched. The published About description lists staking and delegation contract addresses, alongside separate FarmClaim contracts. It also identifies a separate FarmClaim audit. The staking review therefore cannot supply a security conclusion for every later reward component.

FarmClaim handles project-token rewards under each project’s unlocking schedule. Those release conditions differ from staking administration, original airdrop eligibility, and tokenomics allocations. A reward balance and permission to claim that balance describe different states. The next claim depends on the applicable project’s unlocking conditions.

Open full-size image