Liquity v2 ~ Governance (3rd audit)

The current version introduced the logic of enforcing the reset of the users’ allocations every time they want to update them. In addition to that, in Governance::allocateLQTY checks were added to ensure that each Initiative has been provided only once and no double processing could be done for the same address. However, both the resetting and the reallocation invoke the Initiatives’ onAfterAllocateLQTY hook. This means that during a single allocation the hook can be called twice for the same address, possibly breaking the implemented checks in an Initiative.

The new resetting mechanism enforces the users to reset all their allocations before updating their allocations. When resetting, the Governance::_allocateLQTY function invokes the onAfterAllocateLQTY hook on the Initiative.

However, if time sensitive Initiatives existed in the future, which may depend on the timestamps at which the users voted or vetoed for their reward or bribe distributions, resetting and reallocating the users’ votes can inherently affect their accounting and make users lose or get more rewards than supposed to.

The existing BribeInitiative template and the example applications (CurveV2Gauge, UniV4Donations and ForwardBribe) are not time sensitive, but since the protocol aims to support any arbitrary contract as an Initiative, such scenarios are not unlikely to exist.

In the hook function BribeInitiative::onAfterAllocateLQTY, the offset of the user's allocation is taken from _userState.allocatedOffset instead of taking it from _allocation.voteOffset. The value _userState.allocatedOffset corresponds to the offset for all LQTY allocations made by the user (for all initiatives the user voted to). This leads to a wrong calculation of the number of votes from a user for the bribe Initiative. In particular, _userState.allocatedOffset is always greater than or equal to _allocation.voteOffset. So, the user's votes for the initiative will be undervalued (larger offset means less votes) and thus, the user receives fewer bribes than he should. Even worse, the amount of bribes that the user could not claim, due to the bug, remains stuck in the bribe Initiative as no user can claim them. One detail to mention here is that the bug is a race condition based on the position of the bribe Initiative address in the array of initiatives passed by the user to Governance::allocateLQTY function. Having the bribe initiative further in the array leads _userState.allocatedOffset to accumulate more offsets from the other Initiatives’ allocations resulting in a larger value than _allocation.voteOffset and consequently more bribes lost.

function onAfterAllocateLQTY(
    uint256 _currentEpoch,
    address _user,
    IGovernance.UserState calldata _userState,
    IGovernance.Allocation calldata _allocation,
    IGovernance.InitiativeState calldata _initiativeState
) external virtual onlyGovernance {
    ...
    // Dedaub:
    // Should use _allocation.voteOffset instead of
    // _userState.allocatedOffset
    _setLQTYAllocationByUserAtEpoch(
        _user,
        _currentEpoch,
        _allocation.voteLQTY,
        _userState.allocatedOffset,
        mostRecentUserEpoch != _currentEpoch
    );
}

A sample demonstration of the bug can be seen in the following scenario:

• Given a bribe initiative bribeInitiative1 that has $B_n$ amount of bribes deposited for epoch $n$ and two users with some large amount of LQTY deposited at $t_0$.

• Epoch n: user_1 allocates $x$ LQTY for Initiative2 and another $y$ LQTY for initiative bribeInitiative1 by calling allocateLqty([], [Initiative2, bribeInitiative1], [x,y], [0,0]). This call triggers the hook of bribeInitiative1.onAfterAllocateLQTY() with $\text{\_userState.allocatedOffset} = (x+y) * t_0$ (the correct offset should be $y * t_0$).

• Epoch n: user_2 allocates $y$ LQTY for bribeInitiative1.

• Epoch n+1: Both users claim their bribes for epoch n by calling claimBribes({n, n, n}). user_1 receives $\frac{yt_n - (x+y)t_0}{2yt_n - 2yt_0}\times B_n$ and user_2 receives $\frac{yt_n - yt_0}{2yt_n - 2yt_0}\times B_n$. This results in user_1 losing $\frac{xt_0}{2yt_n - 2yt_0}\times B_n$ of his bribe which gets stuck in bribeInitiative1 forever as no one can claim them.

For voting to be fair, it is important that both positive and negative votes have similar costs. Apart from the cost in terms of voting power obtained by staking, we should also consider the actual gas cost of executing the voting transaction. However, the gas cost can be manipulated by a malicious user to make vetos substantially more expensive than votes, exploiting two aspects of the voting design:

• Every call to allocateLQTY calls the onAfterAllocateLQTY which is controlled by the adversary.

• allocateLQTY requires resetting all previous votes and re-casting them, which essentially means that onAfterAllocateLQTY will be called $2 * N + 1$ times for every voting operation, where $N$ is the number of previously voted Initiatives.

• Now consider a malicious user submitting Initiatives whose onAfterAllocateLQTY consumes all available gas in case of a veto, but a tiny amount of gas in case of a vote. Even though the gas is capped by MIN_GAS_TO_HOOK, the current value of 350.000 is large enough to allow a substantial manipulation. With a gas cost of 20 Gwei (not uncommon), calling the hook alone currently costs around $18. There is a scenario in which an adversary can submit $M$ such Initiatives and make the total hook calls when casting vetos for all of them to be $\sum_{N=0}^{M-1} 2 * N + 1$ which is equal to $M^2$. With 10 malicious Initiatives we need $1800 just to call the hooks (not counting the cost of allocateLQTY itself).

• The idea is that the adversary submits the Initiatives on different epochs and votes for them so that they become eligible to get rewards or just stay active in the system for as long as required (for simplicity we do not consider the warm-up periods and similar mechanisms, as they do not directly affect the scenario).

• On epoch_a, the first malicious Initiative becomes active for voting and the users veto it paying the expensive hook call once.

• On epoch_b > epoch_a the adversary’s 2nd Initiative becomes active and the users veto this as well, but also keep their vetos active for the 1st malicious Initiative. Thus, they pay they will have to pay 2 + 1 times the expensive hooks since they have to reset all their allocations (1 call) and reallocate them back (1 call veto of the 1st Initiative) along with their new allocations (1 call veto for the new (2nd) Initiative).

• As can be seen, each new Initiative requires $2 * (M - 1) + 1$ calls to the expensive hooks resulting in the quadratic cost.

• Since 1 Initiative becomes active every epoch, otherwise if all of them were in the same epoch the users could veto them at once and avoid the quadratic cost, the complexity could be also expressed in epochs and be $O(E^2)$ where $E$ is the number of epochs passed.

The direct manipulation of the vetos could be deemed as the most important, but other expressions of the issue also exist that could be used to manipulate specific execution paths. For example:

• Users who have voted for an Initiative that turned out to be malicious or compromised could experience the same issue. Malicious Initiatives detecting vote reduction could similarly treat it as vetoing and consume all the available gas making the hooks expensive.

• Similarly, every resetting operation that even temporarily zeros all the votes before the reallocation could also be used to abuse the system. Any voted malicious Initiative could make any resetting operation quite expensive.

• As a side effect, the vote removal from unregistered Initiatives (as described in L2) could also be used to make the deallocation unfair and expensive for the users who wish to remove their votes from the inactive Initiative.

In the Governance contract, every time an epoch changes, calls to _snapshotVotes update the global state including the boldAccrued which stores the amount of BOLD tokens to be distributed among the Initiatives that became CLAIMABLE in the previous epoch.

function _snapshotVotes() internal returns (
    VoteSnapshot memory snapshot,
    GlobalState memory state
) {
    bool shouldUpdate;
    (snapshot, state, shouldUpdate) = getTotalVotesAndState();

    if (shouldUpdate) {
        votesSnapshot = snapshot;
        uint256 boldBalance = bold.balanceOf(address(this));
        boldAccrued = (boldBalance < MIN_ACCRUAL) ? 0 : boldBalance;
        emit SnapshotVotes(snapshot.votes, snapshot.forEpoch);
    }
}

However, if we assume that the very first operation of the current epoch is an Initiative registration, the BOLD tokens paid as registration fees will be used by _snapshotVotes and will be considered as part of the rewards for the previous epoch. This happens because, inside the registerInitiative function, the fees are transferred to the contract before the snapshots are taken.

function registerInitiative(
    address _initiative
) external nonReentrant {
    // Dedaub:
    // The registration fee is transferred before accruing the BOLD tokens
    // for the current epoch
    bold.safeTransferFrom(msg.sender, address(this), REGISTRATION_FEE);

    require(_initiative != address(0), "Governance: zero-address");

    // Dedaub:
    // This function calls _snapshotVotes which updates the accrued BOLD
    // based on the current balance of the contract
    (InitiativeStatus status,,) = getInitiativeState(_initiative);

    require(status == InitiativeStatus.NONEXISTENT,
      "Governance: initiative-already-registered");

    address userProxyAddress = deriveUserProxyAddress(msg.sender);
    (VoteSnapshot memory snapshot,) = _snapshotVotes();
    UserState memory userState = userStates[msg.sender];
    ...
}

The snapshots should always be the first operation of functions that update the state to ensure that the previous epoch has been properly concluded before any updates for the current epoch are applied.

For a user to be able to register a new Initiative, they need to pay a flat fee of 100 BOLD tokens and have a voting power greater than a percentage of the total positive (“YES”) votes that all the existing Initiatives have gathered. This was done to prevent system abuse by spamming Initiative registrations as the Governance::registerInitiative function is permissionless.

However, even if a user has sufficient voting power to register an Initiative, there exists a race condition in which they can be blocked from registering following the scenario below:

• The user has staked enough LQTY in a previous epoch such that their voting power before the start of the current epoch surpasses the registration threshold.

• In the running epoch, the user stakes an amount of LQTY that increases their offset (newUserOffset).

• Then in the same block, the user tries registering a new Initiative. Following the invariant that when a user stakes more LQTY their voting power at that exact moment remains the same, the user should still be able to perform the registration operation.

• However, this does not happen as the voting power calculation uses the epochStart() to calculate the user’s offset.

• As a result, since totalUserLQTY * epochStart() - newUserOffset < Voting threshold, the user is not able to register a new initiative.

A demonstration of the problem above can be seen in the following graph:

In this scenario, the user deposits 4 LQTY at $t_0$. The user’s voting power is $V_0(t) = 4t - 4t_0$. Now in the next epoch ($n$), if the user wants to register a new initiative his voting power allows him to do so because $V_0(t^e_{n}) > V_T$.

Now consider that the user deposits 1 more LQTY at $t_2$ in the same epoch. The user’s new voting power changes to $V_2(t) = 5t - (t_0+t_2)$. After this deposit the user cannot register a new initiative because $V_2(t^e_{n}) < V_T$.

function registerInitiative(address _initiative) external nonReentrant {
    ...
    uint256 upscaledSnapshotVotes = snapshot.votes;

    uint256 totalUserOffset =
      userState.allocatedOffset + userState.unallocatedOffset;

    require(
      lqtyToVotes(
        stakingV1.stakes(userProxyAddress),
        epochStart(),
        totalUserOffset
      )
      >= upscaledSnapshotVotes * REGISTRATION_THRESHOLD_FACTOR / WAD,
        "Governance: insufficient-lqty"
    );
    ...
}

In the first version, the require statement above used the block.timestamp, but this was changed to epochStart() as part of the changes in the previous version.

In BribeInitiative, the claimBribes function was adjusted to help mitigate rounding errors in the average timestamp calculations from Governance. The last user to claim their bribes may be eligible for more rewards than the existing funds in the contract due to those errors and the function was made so that it adjusts the amount to be given according to the available balance expecting that only the user’s funds will be available.

function claimBribes(
    ClaimData[] calldata _claimData
) external returns (uint256 boldAmount, uint256 bribeTokenAmount) {
    for (uint256 i = 0; i < _claimData.length; i++) {
        ...
        (uint256 boldAmount_, uint256 bribeTokenAmount_) =
          _claimBribe(...);
        boldAmount += boldAmount_;
        bribeTokenAmount += bribeTokenAmount_;
    }

    if (boldAmount != 0) {
        // Dedaub:
        // This adjustment is not sufficient to prevent the last user
        // from claiming the excessive amount of rewards that may
        // originate from the rounding errors of Governance as more
        // BOLD tokens may exist in the contract

        uint256 max = bold.balanceOf(address(this));
        if (boldAmount > max) {
            boldAmount = max;
        }
        bold.safeTransfer(msg.sender, boldAmount);
    }
    if (bribeTokenAmount != 0) {
        uint256 max = bribeToken.balanceOf(address(this));
        if (bribeTokenAmount > max) {
            bribeTokenAmount = max;
        }
        bribeToken.safeTransfer(msg.sender, bribeTokenAmount);
    }
}

However, this assumption is not always valid as anyone could have deposited more tokens for future bribes inflating the available balance. Moreover, the Initiative could have also claimed their rewards from Governance which would have increased the BOLD balance. As a result, the user’s amount will not be adjusted down as it should, but the amount with the rounding errors will be transferred consuming funds originating from other sources.

In the Governance contract, the new offset mechanism is used to account for various issues caused by the average timestamps of the previous versions. When a user stakes LQTY their state gets updated in the following way:

function _increaseUserVoteTrackers(
    uint256 _lqtyAmount
) private returns (UserProxy) {
    ...
    // update the vote power trackers
    userState.unallocatedLQTY += _lqtyAmount;
    userState.unallocatedOffset += block.timestamp * _lqtyAmount;
    ...
}

As can be seen, the offsets encode both the staked amount and the staking timestamp which could alternatively be interpreted as the offset encapsulating the idea of the average timestamps, but in a way that does not introduce the rounding errors of the previous versions.

The following describes the behaviour of the new offset mechanism:

• A user deposits $m_0$ amount of LQTY at $t_0$ which initializes their offset to the value of $m_0 * t_0$.

• Later at timestamp $t_1$ and during the same epoch, the user deposits $m_1$ more LQTY. For simplicity, assume that $t_1 = t_0 + e$, where $e$ some random elapsed time such that $t_1$ remains in the same epoch and $m_1 = m_0$.

• This makes their state become: $unallocatedLQTY = m_0 + m_1 = 2m_0$ and $unallocatedOffset = m_0 * t_0 + m_1 * t_1 = m_0 * t_0 + m_0 * (t_0 + e) = (2t_0 + e) * m_0 = (t_0 + \frac{e}{2}) * 2m_0$

• The value of $t_0 + \frac{e}{2}$ represents the virtual average timestamp embedded in the offset calculations. After the first deposit, the offset included the timestamp $t$ which was moved to $t_0 + \frac{e}{2}$ after the second deposit.

Assuming the above, consider the following scenario which could make users experience more complexity in their interactions or even degradation in their allocations:

• At the time of the first deposit ($t_0$), the user allocates all their staked LQTY ($m_0$) on Initiative_A. This means that the Initiative’s offset becomes: $m_0*t_0$.

• At a later point in time ($t_1$), the user decides to stake more LQTY, as described above, moving their offset to the value of: $(t_0 + \frac{e}{2}) * 2m_0$.

• At the time of the second deposit ($t_1$), the user allocates their remaining LQTY ($m_0$) on Initiative_B. For this process, the protocol requires the user to deallocate all their existing allocations and then re-allocate them back along with the new allocations (this is enforced to account for some broader issues caused by users who (de)allocated their LQTY after depositing or withdrawing affecting their average timestamps and their voting power).

• However, after the user’s second deposit, their voting weight has been uniformly distributed over the new staked LQTY balance which is $2m_0$. This means that when the user allocates back the first $m_0$ LQTY to Initiative_A, it will not receive the same voting power as before because the user’s offset has been increased leading to a degraded voting weight for the same amount of $m_0$ LQTY.

For the above scenario to be prevented, the users should be aware of this property and keep track of their allocations and their staking operations so that they can adjust the LQTY amounts re-allocated to the Initiatives after a new deposit so that they give them the same voting weight as before by increasing the allocated LQTY for those Initiatives which nevertheless introduces some more complexity on the user’s side. For example, in the previous scenario, the user needs to allocate $\frac{t^e_{n+1}-t_0}{t^e_{n+1}-(t_0+\frac{e}{2})}*m_0$ for Initiative_A to preserve the same voting power at the end of the epoch (at $t^e_{n+1}$).

However, there is also a case in which the users cannot rebalance the difference as it becomes impossible to adjust their allocations. This happens during the EPOCH_VOTING_CUTOFF period, in which they are only allowed to allocate back to the Initiatives up to the amount they had previously allocated. This prevents them from distributing their new voting weight so that they do not degrade their votes from previously voted Initiatives, which nevertheless can make them lose part of their bribes due to the degraded votes.

According to the defined specification the invariant that an Initiative can be unregistered if it has been stale (i.e. in a SKIP state) for more than UNREGISTRATION_AFTER_EPOCHS epochs is not followed. For example, in the following scenario a non-stale Initiative can become UNREGISTERABLE:

• Assume that UNREGISTRATION_AFTER_EPOCHS = 4.

• Epoch 1 - 2: Initiatives cannot yet be registered.

• Epoch 3: Assume an Initiative has just been registered.

• Epoch 4: The Initiative exits the warm-up period and becomes eligible for voting.

• Epoch 6: UNREGISTRATION_AFTER_EPOCHS - 1 epochs have passed, since the warm-up period ended, with the Initiative not receiving sufficient votes to become CLAIMABLE in any of the previous epochs rendering it stale during that period.

• Epoch 7: In this epoch, it finally receives enough votes to become CLAIMABLE. If it had not been voted for during this epoch, the Initiative would have become UNREGISTERABLE, as expected.

• Epoch 8: In this epoch, the Initiative is CLAIMABLE, but let’s say its rewards are not claimed. This means that the rewards will be reused and Initiative’s lastEpochClaim will remain 0. Moreover, during this epoch, all voters remove their votes from the Initiative so that it is no longer CLAIMABLE.

• Epoch 9: Now the Initiative can be immediately unregistered since lastEpochClaim + UNREGISTRATION_AFTER_EPOCHS < epoch() - 1 ⇔ 0 + 4 < 7 - 1 ⇔ 4 < 6. However, this breaks the invariant of unregistration since the Initiative was not stale for UNREGISTRATION_AFTER_EPOCHS consecutive epochs as it was CLAIMABLE in the previous epoch.

In the BribeInitiative contract, the _claimBribe function was changed so that it supports the new offset mechanism for calculating each user’s voting contribution. Following these changes, the epochEnd variable was introduced to hold the value of the timestamp at which the epoch that we are claiming for ended.

function _claimBribe(
    address _user,
    uint256 _epoch,
    uint256 _prevLQTYAllocationEpoch,
    uint256 _prevTotalLQTYAllocationEpoch
) internal returns (uint256 boldAmount, uint256 bribeTokenAmount) {
    require(_epoch < governance.epoch(),
      "BribeInitiative: cannot-claim-for-current-epoch");
    ...
    // Dedaub:
    // Seems to be off by 1 second as it calculates the epoch start
    // of the next epoch rather than the end of the requested epoch
    uint256 epochEnd =
      governance.EPOCH_START() + _epoch * governance.EPOCH_DURATION();

    uint256 totalVotes =
      governance.lqtyToVotes(
        totalLQTYAllocation.lqty, epochEnd, totalLQTYAllocation.offset
      );
    if (totalVotes != 0) {
        ...
        uint256 votes = governance.lqtyToVotes(
          lqtyAllocation.lqty, epochEnd, lqtyAllocation.offset);
        boldAmount = bribe.boldAmount * votes / totalVotes;
        bribeTokenAmount = bribe.bribeTokenAmount * votes / totalVotes;
    }
    ...
}

However, its calculation is the same as the one in Governance::epochStart() which means that the epochEnd gets the value of the timestamp at which the next epoch starts and not when the requested epoch ends. As a result, the offset calculations could be off by 1 sec due to the above property.

When an Initiative gets unregistered it can still have active votes and vetos allocated to it which can be reset later. However, when the users deallocate their LQTY, the Initiative’s onAfterAllocateLQTY hook gets invoked even when this has been unregistered.

The existing Initiative implementations are not directly affected from this behavior, but one might have expected that once an Initiative gets DISABLED no more updates would have been expected to be forwarded from Governance. This could cause issues to Initiatives that depend on their registration status in Governance for their accounting in future versions.

We raise this issue here also for visibility in case this was not the intended behavior for unregistered Initiatives.

There are two cases in which some of the bribe tokens could end up stuck in the BribeInitiative contract. More specifically:

• In the BribeInitiative::_claimBribe function, the calculation of the bribe shares for a user is susceptible to rounding errors. For example, if the totalVotes do not divide exactly the user’s votes or the bribe token amount, then the remainder will be left in the contract since the resulting amount is rounded down. These tokens are not reused in the next epochs nor does a way to extract them exist which makes them locked in the contract.

• If the epoch of a bribe passes with no allocations, the bribe’s funds will not be claimable by anyone, and at the same time there is no way to recover them, so they will remain locked in the contract. Although this does not pose any direct issues to the contract’s operation, ways to recover such funds could exist to rescue them in such a scenario.

The new version of the protocol deprecated the average timestamps that previously existed for determining the voting power of an entity and offsets are now used which encodes both the LQTY amounts staked and the staking timestamps. As a result, the Governance::lqtyToVotes function was changed to calculate the voting power based on the distance between offsets.

function lqtyToVotes(
    uint256 _lqtyAmount,
    uint256 _timestamp,
    uint256 _offset
) public pure returns (uint256) {
    uint256 prod = _lqtyAmount * _timestamp;
    return prod > _offset ? prod - _offset : 0;
}

As can be seen above, the function can now be used only with the total amount of LQTY that was used to produce the _offset value with a timestamp greater than or equal to the one that the offset encodes. For example:

• If a user staked at timestamp $t$ an amount of $m$ LQTY, then their offset would become $t * m$.

• The lqtyToVotes for that user cannot be used for any LQTY amount less than $m$ because this would make prod < _offset.

We note this here because, in the previous version, the same function used the average timestamps which allowed getting voting powers with a subset of the total LQTY staked or allocated to an entity.

This functionality is not currently used anywhere in the protocol nor does it seem necessary for it. However, we highlight this difference in case future versions introduce new logic around this function.

In the Governance::_allocateLQTY function, the length checks over the provided arrays have already been performed by the top-level allocateLQTY function. As a result, they can be removed from the internal function since they are also incomplete after the introduction of the offsets as the offset arrays are not checked to have the same length as the rest arrays.

function _allocateLQTY(
    address[] memory _initiatives,
    int256[] memory _deltaLQTYVotes,
    int256[] memory _deltaLQTYVetos,
    int256[] memory _deltaOffsetVotes,
    int256[] memory _deltaOffsetVetos
) internal {
    // Dedaub:
    // These checks have already been performed by allocateLQTY.
    // They are also guaranteed by _resetInitiatives.
    // Moreover, they are incomplete as they do not include the new
    // _deltaOffsetVotes and _deltaOffsetVetos arrays
    require(
      _initiatives.length == _deltaLQTYVotes.length &&
      _initiatives.length == _deltaLQTYVetos.length,
        "Governance: array-length-mismatch"
    );
}

After several refactorings in the Governance::allocateLQTY function, the only meaningful values for the _absoluteLQTYVotes and _absoluteLQTYVetos arrays are positive amounts of LQTY to be allocated to Initiatives. This is because all allocations are reset before any (re)allocation.

As a result, these two parameters could be of type uint256 instead of int256 to avoid confusion during pure deallocations. When fully deallocating, users need to provide all the arrays empty except from the _initiativesToReset, compared to the first version in which a deallaction expected a negative value to be provided.

In Governance::registerInitiative function, there are several parts that could be simplified and save gas on operations that are not necessary for that functionality. For example, in order to check whether the Initiative exists or not the value of registeredInitiatives is sufficient. However, the call to getInitiativeState makes unnecessary calls to _snapshotVotesForInitiative even though the Initiative starts with an empty state. The important factor here is that old Initiatives cannot be re-registered.

In addition to that, getInitiativeState also calls _snapshotVotes which updates the global state. However, the same call is also performed by registerInitiative so that it uses the return values from memory. This means that the storage slots are read twice with no additional benefit for the operations performed.

In the Governance::registerInitiative function in order to determine whether the user has sufficient voting power to register a new Initiative Liquity’s Staking V1 contract is queried to return the total user stakes. However, the same value can also be extracted from the sum of the allocatedLQTY and unallocatedLQTY values from the user’s state saving an external call and also some gas.

In the Governance::withdrawLQTY function if a user requests to withdraw more LQTY than the available amount the execution will only revert when trying to subtract the requested amount from the unallocatedLQTY reverting due to an underflow exception. You could have a check earlier in the function so that you could revert the execution with a more representative error message.

In Governance, the getLatestVotingThreshold function returns the voting threshold based on the cached global voting snapshot. However, this snapshot could be out-of-sync if no other operation that updates the global state has been performed in the meantime. You could maybe document this in the function, like in the previous versions, or use a more representative name for the function since the current one could be falsely interpreted as it always returns the most updated voting threshold.

There are some remaining TODOs in the codebase which you may want to take care of before finalizing the codebase.

The code is compiled with Solidity 0.8.24. Version 0.8.24 has no known bugs at the time of writing.