Mendifinance
Mendifinance staking separates token-specific reward claims from legacy sMendi exits after the protocol sunset.
UpdatedMendifinance staking distributed protocol revenue to MENDI stakers before the protocol sunset. On a first visit after sunset, read the account's existing sMendi position and any token-specific reward credit. The sunset notice described temporary interface access for withdrawals, followed by smart-contract access. A visible Stake button or an old distribution schedule did not establish eligibility for fresh rewards. Read wallet MENDI, staked sMendi, and claimable rewards as different balances. For the selected account, choose a reward claim or a staking exit when its balances support that action; otherwise, stop before signing.
The published legacy staking contract required chain time to reach a pending withdrawal's release time before payment.
Read the legacy staking account before signing
For a first visit, check the selected Linea account for existing stakes and rewards before authorizing any transaction. The legacy screen distinguished wallet MENDI from staked sMendi and displayed claimable MENDI and oLYNX separately. Reading these fields came before choosing a reward control or authorizing a deposit.
While the legacy staking view is available, use the selected token's Claim control for the account's reward credit. A balance field also required account context: values on an unconnected screen could not settle what another wallet held.
Approval established spending permission for a deposit; it did not establish a new stake or a paid reward. The remaining Approve and Stake labels described the deposit interface. Leave new approval unsigned while eligibility for a fresh distribution remains unclear.
Reward completion meant the account actually received the selected token. A displayed claimable figure, a submitted transaction, and a successful token transfer represented different states. Reconciling a claimed MENDI amount with an oLYNX movement would compare different assets. Keep the reward denomination alongside any transaction record used to identify payment.
Before choosing an exit action, read the account's staked sMendi balance and any pending withdrawal. The chosen control needed to match the account's staking state, without treating a reward figure as principal.
Staking controls and the balances they addressed
The retained staking screen separated deposit permission, stake management, and reward collection into distinct controls. A wallet MENDI holding was an input to staking, whereas a claimable MENDI amount described rewards. Neither quantity replaced the staked sMendi balance.
| Control | Balance or permission | Intended action | Relevant limit |
|---|---|---|---|
| Approve | MENDI allowance | Authorize token spending | Permission did not deposit MENDI |
| Stake | Wallet MENDI | Create an sMendi holding | Withdrawal access did not imply fresh reward distributions |
| Unstake | Staked sMendi | Request an exit from staking | Request and payment were separate |
| Withdraw | Pending staking amount | Return underlying MENDI | Recorded release time had to arrive |
| Claim MENDI rewards | MENDI reward credit | Collect that token's rewards | Credit concerned MENDI only |
| Claim oLYNX rewards | oLYNX reward credit | Collect that token's rewards | oLYNX and MENDI remained distinct assets |
| Claim All | Staking reward credits | Collect registered reward tokens | Each token retained its own credit |
Staking controls and the balances they addressed
- Balance or permission (Control) Approve: MENDI allowance Stake: Wallet MENDI Unstake: Staked sMendi Withdraw: Pending staking amount Claim MENDI rewards: MENDI reward credit Claim oLYNX rewards: oLYNX reward credit Claim All: Staking reward credits
- Intended action (Control) Approve: Authorize token spending Stake: Create an sMendi holding Unstake: Request an exit from staking Withdraw: Return underlying MENDI Claim MENDI rewards: Collect that token's rewards Claim oLYNX rewards: Collect that token's rewards Claim All: Collect registered reward tokens
- Relevant limit (Control) Approve: Permission did not deposit MENDI Stake: Withdrawal access did not imply fresh reward distributions Unstake: Request and payment were separate Withdraw: Recorded release time had to arrive Claim MENDI rewards: Credit concerned MENDI only Claim oLYNX rewards: oLYNX and MENDI remained distinct assets Claim All: Each token retained its own credit
A remaining button label did not establish a transaction's availability for a particular account.
Did a 100% revenue share mean a 100% staking return?
The revenue share described distribution policy and did not fix an annual return on staked MENDI. Historically, the staking model allocated 100% of protocol revenue to stakers. An account's rewards also depended on its distribution credit and the relevant reward token. Revenue and the value of the stake were different calculation bases. After sunset, the old allocation percentage could not establish continuing income for a new deposit.
Does Unstake immediately return MENDI?
Unstake and payment were separate operations in the published legacy staking implementation. Burning sMendi increased the account's pending withdrawal amount and assigned a release time. The published legacy staking contract required chain time to reach the recorded release time before a withdrawal. Its owner could change the waiting-time parameter. A remembered cooldown therefore could not establish when a particular pending amount became payable.
Reward tokens and distribution timing
The retained sMendi reward screen named MENDI and oLYNX and gave each a separate Claim control. Its schedule described MENDI distributions once a week at varying times and oLYNX distributions on Wednesdays. The displayed schedule did not confirm further distributions after sunset.
The November 2023 model described revenue rewards in USDC or MENDI. The retained staking screen showed MENDI and oLYNX instead. Those reward descriptions belonged to different contexts and did not establish a single interchangeable asset list. A legacy entitlement had to retain the reward token under which it accrued.
The staking reward contract tracked credits by token and account. Its Claim All function addressed the registered reward-token set in that contract. A claim refreshed the caller's token-specific credit before checking for a positive payout; owning a token with the same ticker elsewhere did not establish that credit.
What happens when the withdrawal interface closes?
The sunset notice described smart-contract access after the temporary withdrawal interface period, without giving a calendar cutoff for that period.
The temporary access notice did not publish a fixed staking cooldown. Direct contract access required the correct staking action and account. It did not combine staking balances with supplied lending assets or allocation claims.
Staking exits remained distinct from lending redemptions and the separate allocation-claim categories. Lending redemptions concerned supplied assets and their market constraints. The allocation screen listed LGE, LGE Bonus, and LINEA for MLP/MLP-L. Those categories did not establish an sMendi reward merely because the same wallet could access them. Choose a staking reward claim for reward credit, an exit for staked or pending MENDI, or a separate allocation claim for an allocation entitlement.
Mendifinance staking - common questions
Can another unstaking request change an existing withdrawal's release time?
Another positive unstaking request reset the release time for the combined pending amount in the published legacy implementation. The contract added the new amount to the existing withdrawal and assigned a fresh release time using its waiting-time parameter. An earlier request's date therefore did not govern the combined amount.
Does Claim All collect LGE and LGE Bonus allocations?
Claim All described staking rewards; it did not establish a combined claim for LGE and LGE Bonus. Those allocations appeared in separate categories with their own MENDI claim controls. The shared MENDI token name did not combine their entitlements into a single staking claim.
Was the displayed 1.0 sMendi to 1.0 MENDI relationship a dollar price?
The displayed relationship expressed token quantities, not a dollar valuation. It paired 1.0 sMendi with 1.0 MENDI on the retained staking screen. It did not establish a dollar price for either token or the amount of a separate reward credit.
Did the MLP label identify extra MENDI available to withdraw?
MLP referred to Mendi Loyalty Points, a separate rewards-program concept. The historical program described those points as a soulbound ERC-20 token for rewarding early contributors. A '+ MLP' label in the annual percentage rate display did not convert points into MENDI principal or establish an account's token allocation.
Would claiming a reward automatically increase the sMendi stake?
The published reward contract transferred a claimed token to the claimant's account without minting additional sMendi. Reward collection and a staking deposit were distinct operations. A wallet receipt therefore established payment of the reward, while an increase in the staked holding required its own staking record.
What did the LYNX and veLYNX options describe in the APR breakdown?
The retained screen placed LYNX and veLYNX under separate oLYNX-related annual percentage rate (APR) options. Those labels did not mean an account held both assets or had already received either one. They also did not specify an exercise or conversion procedure. Their role in that view was to distinguish displayed reward-return options.
Could revoking a MENDI allowance release an existing stake?
Revoking an allowance changed permission to spend wallet tokens; it did not perform a staking withdrawal. Approval, Unstake, and Withdraw addressed different states in the legacy controls. Removing deposit permission therefore did not establish receipt of staked principal or collection of reward credits.