LendlexyzLendlexyz token locking applied different withdrawal rules to staked principal and earned rewards
Lendlexyz token locking placed staked LEND under a fixed 13-week lock in Lendle's historical Mantle Mainnet MultiFeeDistribution implementation. Locked staking principal had to reach its release time. Earned rewards followed a different rule that allowed early withdrawal with a penalty. Unlocked balances could accrue rewards in other tokens, although earning LEND rewards required locked stakes. Lendle later announced a shutdown and asked users to close positions and remove liquidity, so these rules describe the earlier staking design.
Updated -
Bottom line: Historical incentive claims could create locked LEND, so claiming rewards did not necessarily make them immediately withdrawable without a penalty.
Maturity was the normal exit for staked LEND
Staked principal became withdrawable after its lock expired, while earned rewards offered an earlier withdrawal route with a penalty under the historical MultiFeeDistribution rules.
The early-reward withdrawal mechanism applied to earned rewards; it did not provide a paid shortcut for withdrawing unexpired staking principal.
The penalty reduced the earned rewards paid out on an early withdrawal. It did not automatically apply to every LEND balance associated with the account.
Staking also remained separate from lending deposits and borrowing obligations. Lending aTokens tracked supplied assets, while debt tokens tracked loans. Neither balance established that a LEND stake had reached its release time.
Which rewards did unlocked LEND continue to accrue?
Unlocked LEND still accrued other reward tokens in the audited MultiFeeDistribution design, while earning rewards in LEND required tokens deposited with a lock. Actual accrual still depended on the distribution of those other tokens.
Incentive claims and vesting created different withdrawal states
ChefIncentivesController minted claimed incentives into MultiFeeDistribution as locked rewards. Claiming established a reward balance inside the distribution contract. It did not automatically deliver unrestricted LEND into the recipient's wallet.
MasterChef likewise minted rewards only when claimed. Ordinary deposits and withdrawals triggered reward claims, and a dedicated claim function also existed. Those incentives entered MultiFeeDistribution with a lock and retained the early-withdrawal penalty applicable to earned rewards.
TokenVesting followed a different path: claimed allocations became unlocked tokens in MultiFeeDistribution. Allocations vested linearly over a custom duration after the owner started the schedule. That timetable governed the allocation's release, without making each resulting unlocked claim a fresh locked stake.
Both incentive systems were subject to a mint cap. A pending reward amount could exceed what remained mintable. Such an amount did not establish an unconditional balance available for locking or withdrawal.
The fixed lock and variable rewards belonged to different rules
The historical scope was the Mantle Mainnet deployment covered by SourceHat's Lendle Smart Contract Audit Report, updated September 25, 2023. That MultiFeeDistribution implementation fixed its lock duration at 13 weeks. The duration described a withdrawal restriction, without setting the amount that a particular stake would earn.
Reward emissions varied between periods, and the incentive controller's owner could change pool allocation points. Lock length alone could not determine an eventual LEND payout or the value of other reward tokens.
Administrative control also extended beyond reward settings. The StakingConfigurator owner could replace registered proxy implementations and update the MultiFeeDistribution address. The fixed duration belonged to the reviewed implementation; it did not establish unchanged behavior across later replacements.
Why could recorded LEND exceed the amount available for withdrawal?
Recorded LEND could include unexpired staking principal or earned rewards subject to a penalty, so the balance total did not equal an immediately payable amount.
In a hypothetical historical position, an account recorded 173 LEND before its release time, with no matured principal in that entry. The apparent mismatch was that the balance existed, yet none qualified for an unlocked principal withdrawal. That matched the expected state of an unexpired stake.
Reading the entry's balance category and release time left the position unchanged. If the 173 LEND represented locked principal, its contribution to matured withdrawable principal was zero before release. The normal route was maturity followed by an unlocked withdrawal, subject to the deployment's applicable controls. Accepting an earned-reward penalty could not release that principal earlier.
If the same entry instead represented minted earned rewards, an enabled early withdrawal followed the penalty branch. Its net payout was less than 173 LEND. Writing the applicable deduction as P LEND gave a net amount of (173 - P) LEND, without assuming a penalty percentage. The resulting wallet credit and remaining reward balance had to reconcile with that deduction.
A reward-claiming restriction remained distinct from a principal lock. If the intended operation was a disabled reward claim, passing the release time did not re-enable that claim.
The shutdown notice did not announce new staking terms
Lendle announced a shutdown and asked users to close positions and remove liquidity. The notice did not declare all stakes unlocked or state that early-reward penalties had disappeared.
The audited MultiFeeDistribution owner had the power to disable reward claiming. A matured balance alone did not establish that a reward claim remained executable. Expiry addressed the time restriction; it did not reverse that administrative control. For an existing balance, the next decision concerned the withdrawal operation actually available under the deployed rules.
Lendlexyz token locking: frequently asked questions
Was a MerkleDistributor claim window the same as the staking lock?
A MerkleDistributor claim window governed how long a claim record remained redeemable, rather than when its resulting tokens became withdrawable. In the audited design, that window had to last at least one week and could not change after creation. Redemption minted tokens into MultiFeeDistribution with a lock. The claim window and the resulting token lock therefore governed different events.
Did locking LEND burn the tokens?
Locking LEND restricted withdrawal of staked tokens; it did not itself burn them. The audited LendleToken contract had no built-in burning function. Sending tokens to a burn address was a separate action, unrelated to waiting for a staking lock to expire.
Could MasterChef staking rewards go to a different recipient?
The audited MasterChef allowed users to designate where their rewards went. Its owner could also change a user's reward receiver. A pool participation balance therefore did not necessarily identify the address that received the resulting locked rewards. Recipient identity mattered when locating a reward balance for withdrawal.
How did pool allocation points affect the amount of locked incentives?
ChefIncentivesController calculated rewards using elapsed time, the pool's allocation points, and the user's token balance. Its owner could change allocation points. Those inputs affected the incentive amount; the staking lock determined withdrawal restrictions after rewards entered the distribution system.
Were additional reward tokens possible after staking began?
The audited MultiFeeDistribution owner could add reward tokens after staking began. The contract supported distributions in multiple tokens, so the reward asset mattered alongside its amount. That permission concerned the selection of reward tokens, independently of the release time for staked LEND.
Did the stray-token recovery permission cover staked LEND?
The historical recovery permission covered tokens that were neither the staking token nor a reward token. That particular permission did not authorize sweeping staked LEND. Other administrative powers, including implementation changes, remained separate from this restricted recovery function.
How many days were in the 13-week staking lock?
Thirteen weeks equaled 91 days. Describing the duration as three calendar months was less precise because months had different lengths. The conversion expressed the historical duration; it did not supply an individual balance's start time or scheduled release.