xQUESO Audit

The xQUESOToken contract extends functionality from the previous QUESOToken with additional features like a rebasing mechanism, whitelisting, and an override of the transfer functions to enforce whitelist checks. Here are the key points, potential vulnerabilities, and considerations:

General Observations

The contract inherits from ERC20Burnable, Ownable, and AccessControl which are part of the OpenZeppelin contracts. These base contracts are widely used and audited, which helps in reducing the surface area for common vulnerabilities.

The rebasing feature is designed to adjust the token's supply algorithmically, and whitelisting functionality restricts certain actions to approved addresses only.

Specific Observations

Rebasing Mechanism

The rebasing functionality allows the contract to increase the balance of token holders automatically. This feature is complex and can have unintended consequences if not carefully implemented and managed.

The rebase function calculates additional tokens based on a percentage of the user's current balance. While this encourages holding, it also introduces a variable inflation mechanism that needs clear documentation for users.

The use of a cooldown period (rebaseCooldown) between rebases for each user is a good practice to prevent abuse. However, ensuring this mechanism cannot be bypassed or exploited is crucial. To evaluate whether the xQUESOToken contract helps prevent manipulation by timing attacks or artificially inflating balances just before a rebase occurs, we need to consider the mechanisms in place related to the rebasing feature:

Rebase Cooldown: The contract employs a cooldown mechanism for rebasing, controlled by the _lastRebaseBlock mapping and the rebaseCooldown variable. This ensures that each address can only trigger a rebase for itself after a certain number of blocks have passed since its last rebase. This cooldown mechanism is a critical component in preventing rapid, consecutive rebases that could be exploited by timing attacks.

Individual Rebase Tracking: The tracking of the last rebase block per user (_lastRebaseBlock[msg.sender] = block.number;) helps mitigate the risk of an individual user manipulating their balance through immediate actions before and after the rebase. By enforcing a cooldown specific to each user, it restricts the ability to game the rebase timing to artificially inflate balances.

Fixed Rebase Percentage: The rebase percentage is fixed (though adjustable by the owner) and applied uniformly across all balances eligible for rebasing. This means that the potential for gain by artificially inflating one's balance immediately before a rebase would be proportional to the amount of effort (and cost) involved in doing so, including any transactions fees incurred for moving tokens around to appear to have a higher balance.

However, there are areas not directly addressed by these mechanisms that could potentially be exploited:

Publicly Known Rebase Timing: If the timing for when a rebase can occur becomes publicly known or predictable, it may still allow for some level of gaming the system, where users can make transactions to temporarily increase their balance right before a rebase and reduce it immediately after.

Burritos.Cash Response: This is unlike other rebasing protocols. There is a protocol fee when moving from QUESO to xQUESO, and from xQUESO to QUESO. This eliminates the possibility of any users exploiting the returns as they would lose more than they got in their return if they were to try and hop between wallets within a short amount of time. If a user loads up their balance for period of a few days, then yes in theory they can benefit from a return however this brings great risk to them as they would need to be in xQUESO for multiple days until they could even break in and this goes against any sort of stealth attack on the yield. This protocol only allows regular DeFi plays that are not exploitive.

Owner-Controlled Parameters: The owner's ability to adjust the rebase percentage (setRebasePercentage) and cooldown period (setRebaseCooldown) could be misused if not transparently managed. Sudden changes to these parameters could disproportionately benefit those who are aware of the changes in advance.

Burritos.Cash Response: It's hard coded to never be able to go above a 3.69% daily return. We wouldn't ever want to go that high unless it was for a short period of time to reward holders if WPLS were to moon (via Heart's Law) and it wouldn't negatively impact the price.

Whitelisting

Whitelisting controls who can receive tokens through transfer and transferFrom operations, which could be a way to comply with regulatory requirements or control token distribution. However, this also centralizes control to some extent and might limit the open and permissionless nature of the token.

The contract does not restrict who can be whitelisted, leaving it entirely at the discretion of the owner. This power should be handled carefully to avoid centralization and censorship concerns.

Burritos.Cash Response: This is only in place to allow the GateKeeper contract to work as intended. xQUESO cannot be added to any contracts or sent to any wallets unless whitelisted by the owner. The GateKeeper contract is whitelisted at deployment, which allows the xQUESO to flow between the GateKeeper and users wallet smoothly.

Transfer Restrictions

Overrides of transfer and transferFrom to enforce whitelisting could inadvertently limit liquidity and usability of the token in decentralized exchanges or other smart contracts that are not whitelisted.

Consider the implications of these restrictions on the token's ecosystem and whether alternative mechanisms can achieve similar goals without overly restricting token flow.

Burritos.Cash Response: This is intentional as it prevents the chance of xQUESO being exploited against QUESO. If both had their own LP, the project would implode. Also, if users could send the xQUESO to any other wallet, they would have been able to abuse the daily rewards. This solves that.

Security Considerations for Rebasing

Ensure that the rebasing mechanism cannot be manipulated by timing attacks or by artificially inflating balances just before a rebase occurs.

The rebasePercentage limit of 3.69% should be carefully considered in the context of the total supply and frequency of rebases to prevent excessive inflation.

Burritos.Cash Response: This is why the returns are daily via the correct amount of blocks.

Access Control

The use of AccessControl for managing roles related to minting, burning, and rebasing is good practice. It is essential to manage these roles securely throughout the contract's lifecycle.

The contract allows the owner to grant and revoke roles, which is standard, but ensure that these capabilities are used judiciously to maintain trust in the contract's governance.

Recommendations

Consider User Experience: Ensure that the implications of rebasing and whitelisting on user experience are well understood and communicated. This includes understanding how rebases affect token holdings and the impact of transfer restrictions.

Made possible by AI.