FastLane Protocol

Proof of concept: PoC

The function agentWithdrawFromCommitted is meant to let a policy agent to pull from a user's committed balance while paying a fee to the atomic pool.

This function has an isUnderlying argument that allows the caller to request the withdrawal to be denominated in MON.

When the isUnderlying argument is set to false it first converts the share amount to gross assets, both gross and fee, the code then explicitly sets _assetsToReceive = gross - fee.|

However, when the isUnderlying argument is set to true the function is meant to take the specified amount as net and calls _getGrossAndFeeFromNetAssets returning both gross and fee, however, when there is not enough liquidity in the pool, the function will cap the returned gross amount while maintaining the original net amount as the amount to transfer.

This not only leads to the agent with being able to bypass the liquidity cap but also to seize the fee meant to buffer the float and capture protocol revenue, but also leaves the pool insolvent relative to its accounting, as the function calls in both cases function _accountForWithdraw(uint256 netAmount, uint256 fee).

Which expects the netAmount to be passed along with the fee, whereas in this case, the gross amount is being sent along with a fee that is never captured producing a mismatch between the protocol accounting and the real protocol state.

Moreover an agent can repeat the operation whenever the pool refills, harvesting the entire liquidity each time while paying zero utilization fee and leaving other users without the ability to instant withdrawal.

After calling _getGrossAndFeeFromNetAssets, calculate the deliverable net by calculating gross - fee and if it doesn't match the requested net amount either revert or return the actual net amount.

FastLane Team: The issue was resolved in PR#532.

Proof of concept: PoC

The _accountForWithdraw function manages accounting for instant withdrawals from the atomic unstaking pool. It allows withdrawals up to s_atomicAssets.allocatedAmount plus globalRewardsPtr_N(0).earnedRevenue.

The issue arises when allocatedAmount is depleted and a shortfall is covered using earnedRevenue. In this case, the function increases allocatedAmount by the shortfall amount.

As a result, subsequent checks compare _distributedAmount + netAmount against an inflated _allocatedAmount + _earnedRevenueOffset, effectively expanding the withdrawal limit.

A user can repeatedly perform instant withdrawals as long as each withdrawal remains below earned revenue, gradually draining the contract and consuming funds reserved for other protocol operations.

Modify _accountForWithdraw to properly account for already used earnedRevenue, ensuring instant withdrawals cannot exceed the combined allocated and earnedRevenue amount.

FastLane Team: The issue was resolved in PR#587.

In StakeTracker._crankGlobal(), in the _checkSetNewAtomicLiquidityTarget call, there is the possibility of an overflow, in a specific scenario:

• There has been an atomic unstake
• A large amount of shMON has been requestUnstaked

This causes equity to be very small, because most funds are offset by a liability to represent the unstake request.

Then, when we get to the global crank phase after that setup, in _checkSetNewAtomicLiquidityTarget we calculate _newScaledTargetPercent as s_atomicAssets.distributedAmount / _totalEquity . This figure can be reach into the thousands of percents, and has in live testnet deployments.

The overflow and revert then occurs when we call _unscaledTargetLiquidityPercentage() and pass in this value when it is larger than 655% (the max a uint16 can hold, when represented in basis points)

Thus, the crank cannot complete, and therefore the users who requestUnstaked can never reach the epoch where they can call completeUnstake, so funds are stuck.

Cap the calculated _newScaledTargetPercent at 100%, and do an “emergency” decrease of allocated and distributed amounts in _afterRequestUnstake if the unstaked amount + allocated + recent revenue is > total equity.

FastLane Team: The issue was resolved in PR#557.

Proof of concept: PoC

According to the comments in the code documenting the top-up mechanism. When a user's committed balance falls below minCommitted, the system attempts to commit more shares from their uncommitted balance. However, this is not always true.

When the _spendFromCommitted function processes an agent's spend, it computes fundsAvailable as the caller’s current committed balance minus any holds and only invokes _tryTopUp if the requested shares exceed that pre‑spend amount.

Consequently, as long as the agent keeps each transfer less than or equal to the balance that is already committed, the top‑up path never runs. The committed balance is decremented immediately without ever triggering a top-up from the user's uncommitted funds.

This defeats the intended guarantee that the auto‑top‑up keeps at least minCommitted shares available.

Trigger the top-up when the updated fundsAvailable is below the shares + minCommited

FastLane Team: The issue was resolved in PR#573.

The agentTransferFromCommited function prevents agents from uncommitting their own balance from a policy.

However, a malicious agent can shuffle their committed balance to any non-agent function they own using this function then immediately after call agentTransferToUncommitted to transfer the funds back to themselves. Bypassing the protection.

Prevent agents from transferring their own committed balances to non-agent addresses without a delay.

FastLane Team: The issue was resolved in PR#586.

The _rollValidatorEpochForwards function advances the validator epoch state and updates accounting for each validator. At the end of this process, a validator is queued for deactivation when both s_validatorData[valId].inActiveSet_Last and s_validatorData[valId].inActiveSet_Current are false.

However, newly added validators start with s_validatorData[valId].inActiveSet_Current at its default value of false, which then causes _advanceActiveSetFlags to set inActiveSet_Last to false.

If the first crank involving that validator experiences a failure that sets inActiveSet_Current to false again, the deactivation condition is met immediately.

As a result, the validator can be deactivated after just one failure, bypassing the intended two-strike mechanism that applies once a validator has prior epoch history. This situation can occur when a validator is added on Monad during the delay window and becomes active in epoch n+2.

Ensure newly added validators are initialized with appropriate active set state or implement a grace period before applying standard deactivation logic, preventing unintended single-failure removals.

FastLane Team: The issue was resolved in PR#552.

Proof of concept: PoC

The _handleCompleteDecreasedAllocation function compares the received amount from a withdrawal to the undelegated expectedAmount and books any excess as “surplus.” On Monad, a withdrawal can include both the returned principal and rewards accumulated during the exit window.

As a result, the excess over expectedAmount often represents earned rewards rather than surplus capital. Currently, this excess is redirected and potentially re-staked through queueToStake, bypassing the standard reward handling path.

This causes validator rewards to be misclassified as surplus, skipping commission, underreporting earnedRevenue, and distorting validator performance metrics used for allocation.

When amount > expectedAmount, treat amount - expectedAmount as validator rewards and process it through the same reward-handling logic used in _handleEarnedStakingYield to ensure proper accounting.

FastLane Team: The issue was resolved in PR#549.

agentBoostYieldFromCommitted calls _handleBoostYield, which books revenue and increases queueToStake even though no new MON arrives and the committed shares are already staked.

During crank(), this synthetic queueToStake can be netted in _settleGlobalNetMONAgainstAtomicUnstaking or reduced alongside queueForUnstake in _offsetLiabilitiesWithDeposits when there are uncovered liabilities and sufficient current assets, pushing genuine withdrawals or other payments into later epochs.

The call also inflates globalRewardsPtr_N(0).earnedRevenue. The instant-withdraw path relies on that value as an offset: if distributed + netAmount > allocated, it will allow the withdrawal so long as allocated + earnedRevenue covers it, then enqueue the shortfall to queueForUnstake and increase allocatedAmount.

When earnedRevenue was boosted without new cash, the contract still pays out immediately by drawing on liquid assets. This overstates near-term liquidity and forces liquidity to come from other areas, such as reservedAmount, until the backfilling unstake settles.

Keep queueForUnstake and revenue tied to real inflows so staking, withdrawals, and instant-withdraw capacity reflect actual liquidity.

FastLane Team: The issue was resolved in PR#580.

The atomic unstake paths (withdraw, redeem, agentWithdrawFromCommitted) price every withdrawal off the current utilization snapshot returned by _getLiquidityForAtomicUnstaking.

Each successful instant unstake immediately increments s_atomicAssets.distributedAmount in _accountForWithdraw so the next withdraw is repriced at a higher fee rate.

An MEV bot that holds shMON can observe large instant withdrawals in the mempool and front-run them with a tiny redeem/withdraw first to push utilization up and pocket the victim's extra fee via it's remaining shMON balance.

Because the fee curve is affine (fee(u) = c + m·u) with m = 1% by default, even a small utilization bump significantly raises the victim’s fee. A holder with just ~1% of the supply already profits from this attack.

Add slippage controls to every instant-unstake path so users aren’t forced to execute at a worse fee than they previewed.

FastLane Team: The issue was resolved in PR#583.

Proof of concept: PoC

When solveGrossGivenNet (used by withdraw and previewWithdraw) enters the quadratic branch, it computes (2*m*RAY*targetNet)/L inside Math.mulDiv, any withdrawal request with a targetNet greater than (2^256-1)/(2*m*RAY) will result in an overflow.

With DEFAULT_SLOPE_RATE_RAY m = 1% (1e25), any withdrawal request above 5.79M MON causes the intermediate product to exceed 256 bits, so Math.mulDiv reverts with MulDivFailed() before applying liquiditycaps or fees.

Raising the slope rate will proportionally reduce the overflow threshold.

Replace the 256-bit function mulDiv with the 512-bit version fullMulDiv

FastLane Team: The issue was resolved in PR#532.

The targetStakedAmount function determines the protocol’s next staking allocation based on available equity after accounting for required float.

It computes totalEquity as _totalStaked + nativeTokenBalance - totalLiabilities, where totalLiabilities includes liabilities.redemptionsPayable, liabilities.rewardsPayable, and admin.commissionPayable.

To derive the staking target, the function subtracts _targetAtomicAllocatedAmount and workingCapital.reservedAmount from this equity.

The issue arises because some liabilities are already reflected in both components. In _handleValidatorRewards, when liabilities.rewardsPayable increases, reservedAmount also increases by the same value.

Similarly, _handleCompleteDecreasedAllocation tops up currentLiabilities to cover liabilities.redemptionsPayable, which are also reserved until redemption.

As a result, the targetStakedAmount calculation deducts these amounts twice, once as liabilities and again through reserved assets leading to an understated staking target and potential underutilization of available equity.

Adjust the targetStakedAmount computation to avoid double-counting obligations that are already captured in both totalLiabilities and reservedAmount.

FastLane Team: The issue was resolved in PR#589.

When cranking an inactive validator at (StakeTracker.sol:638-650) the protocol unstakes only _validatorUnstakableAmount and sets _nextTargetStakeAmount = 0.

However, _validatorUnstakableAmount is calculated as targetStakeAmount - pendingStaking. This means the pendingStaking amount would be excluded from the decrease allocation that should happen for same validator next epoch, leaving pending funds unaccounted.

Example:

Validator has 100 ETH target + 10 ETH pending. When inactive, only 90 ETH is queued for unstaking and nextTarget becomes 0.

The 10 ETH pending stake remains locked indefinitely.

Consider assigning difference between previous targetStakeAmount and _validatorUnstakableAmount as next target stake amount.

FastLane Team: The issue was resolved in PR#563.

The changeCommittedTotalSupply boolean parameter in the internal _commitToPolicy() function is always passed as true in all three call sites (lines 55, 78, 185). The conditional check on line 513 serves no purpose as the flag is never set to false.

function _commitToPolicy(
uint64 policyID,
address accountFrom,
address sharesRecipient,
uint256 shares,
bool changeCommittedTotalSupply  // Always true
)

Consider removing the changeCommittedTotalSupply parameter and the conditional check and always incrementing s_supply.committedTotal when committing shares.

FastLane Team: The issue was resolved in PR#555.

The implementation assumes EOA signers and does not support ERC-4337 smart contract wallets or other account abstraction methods that are becoming increasingly common.

Consider adding support for ERC-1271: Smart contract signatures.

FastLane Team: The issue was resolved in PR#578.

The process function calculates commission based on the coinbase contract’s entire current balance, distributes the commission, and then attempts to send the remaining rewards to delegators. If the payout to delegators fails, those untransferred rewards remain in the contract.

On the next process call, commission is recalculated on the full balance again, including the previously retained rewards. This effectively applies commission again to the same rewards, reducing the amount available to delegators.

Ensure commission is only calculated on newly accrued rewards, excluding any balance carried over from prior failed distribution attempts.

FastLane Team: The issue was resolved in PR#551.

denullifyEligibilityMap is public with no access control, allowing anyone to modify s_valEligibility mapping.

The s_valEligibility mapping (Storage.sol:102) is never read in any protocol logic.

Only used in a view function getter, suggesting it's dead code.

Protocol confirmed in discussions that this is a deadcode.

Consider removing the s_valEligibility mapping and associated code.

FastLane Team: The issue was resolved in PR#570.

The internal function _queueNetDepositsForStaking() at StakeTracker.sol: 1460 is defined but has no callers in the codebase.

function _queueNetDepositsForStaking(uint256 amount) internal {
// Function body exists but is never called
}

Consider removing deadcode.

FastLane Team: The issue was resolved in PR#579.

maxWithdraw reports a net-asset amount based on _convertToAssets(..., Floor) while previewWithdraw inverts the path with _convertToShares(..., Ceil) to cover fees.

As a result the preview rounds the required shares up, so a user can request assets equal to maxWithdraw yet be asked to burn more shares than they actually have in balance.

Align the runtime withdraw flow with the same rounding and liquidity-aware math used in maxWithdraw.

FastLane Team: Given recent exploits involving rounding and precision issues, we are purposefully making these rounding choices in favor of the security of the protocol.

We round down when users specify shares, to give them a conservative amount of assets they can definitely withdraw (maxWithdraw).

We round up when users specify assets, to give them a conservative number of shares they need to burn to get those assets (previewWithdraw).

In both cases we round in favor of the protocol and not the user. Changing either of these would sometimes round in favor of the user, and even though its fairly inconsequential (1 wei), we think we should always round defensively in favor of the protocol.

When cranking the linked list of validators, validators are primarily identified using their block.coinbase addresses which are stored in this linked list.

Each of those addresses is passed into StakeTracker._crankValidator(), and an associated validator ID is looked up. That validator ID is then passed into any internal functions.

This assumes that validator ID <> coinbase is strictly 1:1 relationship. However that assumption is incorrect - validator IDs are unique but many IDs can map to the same coinbase address.

This means that the same coinbase address could be used multiple times in that linked list, which would always map back to the same validator ID.

This relationship is protected at the stage where the owner adds validators to ShMonad, but in reality we will need to support validators that map to the same coinbase.

Refactor the linked list and any other identifying logic to always use validator ID, and only look up coinbase from ID at the point where it is required in the logic (e.g. to call process())

FastLane Team: The issue was resolved in PR#593.

A malicious actor can frontrun MEV reward distribution by directly delegating to validators via the Monad staking precompile immediately after MEV is earned in epoch N.

Since FastLane distributes MEV rewards to validators in epoch N+1 (via externalReward()), and direct delegations become active in N+1, the attacker receives a proportional share of these rewards without taking any performance risk.

This creates a risk-free profit opportunity that can be exploited repeatedly every epoch.

Example scenario:

Epoch 5: MEV reward is generated for validator V1.

Epoch 6 crank starts:

• Global crank passes.
• Validator crank begins.
• Validator rewards from Epoch 5 are credited to V1.

Since it is deterministic that the reward will be credited in Epoch 6, an attacker can delegate to V1 in Epoch 5, just before the epoch boundary, and receive a share of the reward without having participated in validation.

Attackers can repeatedly capture validator MEV rewards with no stake-performance exposure.

If considered an issue, a straightforward mitigation would be to send validator rewards immediately as they are earned, rather than deferring to the next epoch.

However, this may require a broader architectural refactor of the accounting.

Other solution is enforcing that sendValidatorRewards is only called during boundary period of epoch, hence even if someone notices and delegates later, their delegation would be active from n+2.

FastLane Team: We do not perceive this to be an issue at this time. It is an unfortunate side effect of the Monad staking design. Full mitigations are impossible, and partial mitigations would only work for MEV earned during the boundary block - a very small percentage of the overall MEV. We do not believe a minor mitigation is worth the extra complexity.

Note also that if we could deposit the validator rewards when they’re collected then we would, but MEV transactions are the most gas-sensitive of any transaction type, and the external reward function is quite gas intensive. External rewarding in each MEV transaction is a non-starter. Running a second crank would not fully solve the issue, either.

We’re lobbying the monad team for the deposit wait period to be the same as the withdrawal wait period (1 epoch - 2 in boundary) rather than its shorter, current duration (0 - 1). From our POV, that is the only real solution.

Validators can manipulate stake allocation by:

Self-delegate large amounts on Monad (not via FastLane) Call sendValidatorRewards() to spike their earnedRevenue Next epoch's allocation uses avg of epochs n-1, n-2 Validator receives outsized share of queueToStake

Attack Economics:

Validator with 10 FastLane stake, self-delegates 80 (total 100) Donates X rewards → loses only 20% (10% to FastLane, 10% to others) Gains larger stake allocation worth more than 20% cost Most profitable in early stages when FastLane share is small

Code:

// StakeAllocationLib.sol:67-72
targetDelta = queueToStake * validatorRevenue / globalRevenue;
// StakeTracker.sol:444 - uses n-1, n-2 epochs
earnedRevenueLast: globalRewardsPtr_N(0).earnedRevenue    // n-1
earnedRevenueCurrent: globalRewardsPtr_N(-1).earnedRevenue // n-2

Use n-2, n-3 epochs instead of n-1, n-2 to add 1-epoch delay, preventing immediate manipulation.

FastLane Team: This finding is a design choice of shMonad. Validators can freely bid for deposits each crank. You can monitor validator bidding here:

https://analytics.shmonad.xyz/stake-distribution

Validators must keep in mind two costs:

1. The Fastlane fees taken on rewards
2. The validator bid would have to be sustained otherwise the algorithm will naturally start undelegating from that validator as soon as they

stop bidding

This design allows shMonad holders to capture increase yield from validators bidding for deposits

Please note:

• We’re not planning to change the smoothing window (n‑1/n‑2 ➝ n‑2/n‑3); adding another delay would slow legitimate 37 responsiveness without preventing repeated donations.
• Operationally, we’ll monitor bidding strategies from validators and may change the algorithm in the future

disablePolicy() function allows any single policy agent to irreversibly disable the entire policy, affecting all other agents and users.

Consider allowing only primary agents to disable policy

FastLane Team: This is a design choice of the agent and policy system. Appointing agents is a permissioned action that we control, so any agent is a trusted entity.

When boostYield() is called, it attributes the boosted yield to the current active validator's earnedRevenue, even though the boost may be unrelated to that validator's performance. This skews validator performance metrics.

Consider not attributing boosts to the current validator.

FastLane Team: This is a design choice of the system. The function should always attribute to the current block’s producer. If someone wants to attribute earnings to a different validator but still give all earnings to shMON holders, they should call sendValidatorRewards() with a 100% fee and specify a validatorID

createPolicy(uint48 escrowDuration) accepts any 48‑bit duration without bounds. A policy owner can set escrowDuration near type(uint48).max (~9e13 blocks), and anyone who later deposits/commits into that policy will be unable to finish completeUncommit in any practical time frame.

Because escrowDuration is immutable per policy and users often rely on pre-existing policies, this acts as an effectively permanent lock on their liquidity.

Enforce a sane upper bound when creating policies.

FastLane Team: The issue was resolved in PR#554. This is a design choice of the system, specifically to support restaking usecases built on top of ShMonad policies which require explicit approval to release funds, and should not be circumvented by a finite escrow duration.

Both totalSupply() and realTotalSupply() return identical values by calling the same internal function _realTotalSupply().

Unlike previous versions where these functions returned different values, they are now redundant. This adds unnecessary code and potential confusion for integrators.

function totalSupply() public view returns (uint256) {
return _realTotalSupply();
}
function realTotalSupply() external view returns (uint256) {
return _realTotalSupply(); // @audit why two supplies only one is fine
}

Consider removing the realTotalSupply() function entirely and rely solely on the standard totalSupply() function for consistency with ERC20 standards.

FastLane Team: This is left in intentionally to support isolated staking (to a specific validator). This version of shMonad has removed the feature, but we intend to add it back in a future upgrade.

In _removePolicyAgent, when the primary agent is removed, the function assigns whoever was last in the array as the new primary. This is arbitrary - the last agent may not be qualified or authorized for the primary role.

Consider passing flag for who should be next primary agent.

FastLane Team: The design of the agent and policy system does not differentiate between “primary agents” and other agents and there is no intention to differentiate between the two. We added a “primary agent” to save gas as it is included in the initial SLOAD of the Policy struct while other agents would require another SLOAD in the modifier check.

The yieldOriginator address is user-provided input in boostYield(), allowing anyone to claim yield came from any address. This could confuse UIs, indexers, or analytics tracking yield sources

Consider validating yieldOriginator is msg.sender or beware of this risk associated.

FastLane Team: This is a design choice of the protocol. yieldOriginator is for our own internal tracking via events, and is intended to be the bundler or DAppControl address of the Atlas metacall that generated yield. Atlas is not part of this audit, but you can learn more about Atlas here:

https://www.atlasevm.com/

The _recentRevenueOffset() mechanism deducts recent revenue from equity calculations during withdrawals, meaning legitimate users who need to withdraw after revenue events receive less value. While this protects against JIT attacks, it creates UX friction for normal innocent users.

Be aware this is a tradeoff between security and user experience. Consider documenting this behavior clearly for users.

FastLane Team: This is intentional design of the system and we will make it clearly documented to users of the protocol.

When a user requests uncommit (triggering escrow period), agents can still immediately use those uncommitting funds via _spendFromCommitted() without checking if escrow has completed.

Potentially confusing users who expect their funds to be locked during escrow and later available for withdrawal.

Consider documenting that escrow only restricts users, not agents

FastLane Team: This is intentional design of the system and we will make it clearly documented to users of the protocol.

While the deposit function returns the number of shares minted for the amount of MON sent. The depositAndCommit function which does the same but committing the shares afterwards doesn't.

Leading to difficulties for other integrators to know the number of minted shares.

Return sharesMinted as part of the function.

FastLane Team: The issue was resolved in PR#556.

__AtomicUnstakePool_init() silently applies the hard-coded fee curve whenever both mRay and cRay are zero.

On a fresh proxy that behavior is fine, but it also means you can’t feed custom parameters during initialization, the owner must overwrite the defaults immediately after the upgrade if he was to change it.

Consider accepting initializer inputs or documenting the post-init step.

FastLane Team: The protocol has been deployed, so this function is no longer relevant.

addValidator(uint64 validatorId, address coinbase) lets the owner register any coinbase contract for a validator.

During _crankValidator, the system calls that coinbase via ICoinbase(coinbase).process() with all remaining gas (src/shmonad/StakeTracker.sol: 684-699).

Although wrapped in try/catch, the call isn’t gas-limited—if the callee deliberately burns all gas (e.g., endless loop or heavy computation), the outer _crankValidator runs out of gas before reaching the catch, causing the entire crank transaction to revert.

Before adding a validator, vet the coinbase contract (or use an audited template) to ensure its hooks can’t stall crank(). If you must interact with an untrusted implementation, wrap those calls in a bounded-gas/try-catch path so a misbehaving validator can’t brick the epoch processing.

FastLane Team: The issue was resolved in PR#590.

Storage.N(int256 nDelta) just adds nDelta to s_admin.internalEpoch inside an unchecked block and applies % EPOCHS_TRACKED. There’s no guard that the caller stays within the tracked window.

Passing nDelta = 8, -9, or any other value simply wraps around the 8-slot ring and hands back a slot that might be in active use.

The codebase only calls *_Ptr_N() with small, hard-coded offsets ([-3 … +2]) today, but because the helper is exposed to the whole codebase and widely used, someone could add a future call with an unbounded or user-supplied delta.

If they overshoot, they’ll silently read/write the wrong epoch bucket.

Document this risk properly or add bounds based on the number of epochs tracked.

FastLane Team: We have no intention to add a user supplied delta to the system.

Since a user's committed balance is excluded from balanceOf, it breaks the usual ERC20 invariant that the sum of all user balances equals the total supply.

This won’t cause any issues per se, but it’s something to be aware of for analytics teams.

Consider documenting this

FastLane Team: This is intentional design of the protocol and we will work with analytic or frontend teams to correctly account for user balances.

The crank allocates queued stake to validators proportionally based on their earned/global revenue. This results in cold start problem initially.

When all validators are newly added, both validator and global earned revenue are zero, resulting in no stake allocation. However, this is solvable by sending validator rewards or boosting yield to jumpstart the system.

Now, once a group of validators has established their stake and revenue, new validators face significant barriers to entry:

1. New validator joins with earnedRevenue = 0
2. Receives 0 stake allocation: 0 / globalRevenue = 0%
3. Without stake delegation, cannot earn organic revenue from validation alone.
4. Must get revenue by sending validator rewards or triggering boost yield.

Be aware of this game-theoretic dynamic when operating FastLane.

FastLane Team: The system is live, so no longer relevant.

The protocol's PrecompileHelpers and related contracts make various assumptions about the Monad staking precompile's behavior.

All testing is currently done against MockMonadStakingPrecompile, not the actual production precompile.

If the production Monad staking precompile behaves differently from the mock, it could result in issues,

Beware of the risk associated. Once precompile is in production, consider running test suite with it and reviewing it for compatibility with helpers contract.

FastLane Team: The system is live on both mainnet and testnet running against the actual pre-compile.

The targetAtomicAllocatedDelta and targetStakedDelta functions in AccountingLib are not used.

Consider removing deadcode.

FastLane Team: The issue was resolved in PR#584.

Proof of concept: PoC

During the validator crank loop, validators are processed sequentially.

When for a certain validator a undelegate() is called, it immediately increments s_globalPending.pendingUnstaking.

This directly reduces globalUnstakableAmount (calculated as stakedAmount - pendingStaking - pendingUnstaking) for all subsequent validators in the same crank cycle.

Which affects their allocations and can cause underflow and revert.

The issue occurs because queueForUnstake is cached at the start of the crank, but globalUnstakableAmount is recalculated fresh for each validator using the live s_globalPending state.

When validator N undelegates, it increases pendingUnstaking, which decreases globalUnstakableAmount for validator N+1. If validator N+1's allocation is calculated assuming the new globalUnstakableAmount, the formula:

_stakeAllocationDecrease = queueForUnstake * validatorAmountAvailableToUnstake / globalAmountAvailableToUnstake

can produce a _stakeAllocationDecrease larger than expected, leading to underflow at: targetValidatorStake = validatorEpoch_Last.targetStakeAmount - netAmount;

Consider caching pendingUnstaking at the start of the crank cycle

FastLane Team: The issue was resolved in PR#611.

When agentWithdrawFromCommitted is called with amountSpecifiedInUnderlying == false, it converts the requested shares to gross assets and caps that gross via _getGrossCappedAndFeeFromGrossAssets.

If the cap triggers (low liquidity), _assetsToReceive reflects only the capped gross minus fee, but _sharesToDeduct stays equal to the original amount.

_spendFromCommitted then burns the full requested shares even though the pool delivered fewer assets, so the caller loses more shMON than the payout justifies

Recompute _sharesToDeduct from _grossAssetsCapped before calling _spendFromCommitted, or revert when _grossAssetsCapped < _grossAssetsWanted to avoid inconsistent burns.

FastLane Team: The issue was resolved in PR#612.

Proof of concept: PoC

maxWithdraw calculates a user’s withdrawable amount by converting their share balance through the forward path (shares → assets), which floors the result and then applies fees and caps.

When the user later calls withdraw, the contract reverses that value using _previewWithdraw, which follows the inverse path (net assets → gross assets → shares) and uses ceiling rounding.

Because the forward and inverse paths round differently, the amount returned by maxWithdraw can translate back into more shares than the user holds, causing _burn to revert with ERC20InsufficientBalance.

Align maxWithdraw with the path and rounding used in _previewWithdraw so the returned amount never maps back to more shares than the caller owns.

FastLane Team: Acknowledged.