Neemo Exploit Reimbursement Plan

Astar
1

TL;DR

  • What went wrong
    • On 5 July 2025, a compromised admin key allowed an attacker to over-mint nsASTR and nrETH, drain liquidity, and initiated an unstake of underlying assets of nsASTR/nrETH
    • Only the immediate intervention of the Main Council and Astar Collective prevented catastrophic loss.
    • Astar Treasury now safeguards 204,283,546.036 ASTR; a white-hat has returned 91.634 ETH.
  • Why this proposal matters
    • This proposal has been developed with input from the Neemo community, the Astar community, Astar Main Council, the Astar Collective and the relevant DeFi protocols
    • Thousands of users have funds frozen or de-pegged; trust in Neemo and the wider Astar ecosystem is at stake.
    • We must reimburse victims swiftly, transparently.
  • Two-phase recovery plan
    1. Phase 1 – Immediate burn-for-refund
      • Burn hacker tokens, lock minting, open always-on burn contracts.
      • Users receive 100 % of their entitlement at burn time; suspicious wallets can be quarantined.
    2. Phase 2 – Long-term refund
      • 100 % of Neemo’s dApp-staking rewards (minus bare-minimum ops) stream monthly to the compensation pool until pre-hack rates are fully restored.
  • Compensation model
    • Split Model
    • Asset-linked model
    • Unified pool model
  • Next steps
    • Forum discussion and decide the compensation model → On-chain vote → Deploy reimbursement contracts

Overview

First and foremost, we would like to sincerely apologize again to all affected users and the entire Astar community for the distress and inconvenience caused by the exploit.

Thanks to the swift and decisive action of the Main council and Astar collective, 204,283,546.036 ASTR has been successfully protected. Additionally, 91.634 ETH has been returned through a white-hat bounty by address: 0xb750E3165de458EaE09904cc7fad099632860b0f.

We respectfully request that the Astar community support the return of these recovered assets to the new reimbursement contracts once they are deployed.

The compensation process will be structured in two distinct phases, which will be outlined shortly in detail. We welcome any feedback or suggestions at this stage and deeply value the input of the community before proceeding to governance.

Phase 1 – Immediate Refund via Token Conversion

1 Upgrade minter contracts

Add a burn() function to both nsASTR and nrETH minters.

2 Burn exploiter tokens & halt minting permanently

  • Burn all excess nsASTR / nrETH in hacker wallets.
  • Disable any future minting.

3 User token recovery

  • Users withdraw all remaining nsASTR / nrETH (including DeFi positions) to self-custody.

4 Finalize final reimbursement rate

  • After the burn, compute accurately:
    • legitimate circulating supply
    • total recovered ASTR & ETH
    • final reimbursement rate

5 Deploy reimbursement contracts

  • Two contracts (one per token) that
    1. accept deposits,
    2. burn deposits,
    3. return ASTR or ETH at the calculated rate.
  • Secured by 3-of-4 multisig: Neemo CEO (3 separate Ledgers) + CTO (1 Ledger).

6 Emergency withdrawal

  • External Advisors + Neemo Multisig can jointly trigger an emergency withdraw.

7 Burn-for-refund workflow

  • Open burn and redeem window
    • Users deposit and burn nsASTR or nrETH.
    • Refunds are distributed immediately based on the current compensation rate.
  • Ongoing redemptions
    • Users who missed the initial burn window can still burn and redeem their tokens for 100% based on the compensation rate.
    • Addresses flagged for suspicious behavior may be delayed, capped, or excluded.

8 Compensation & fraud controls

  • Compensation
    • Immediate refund: All eligible nsASTR/nrETH users receive 100% of their calculated refund at the time of burn based on the fixed compensation rate.
    • Chunk-1 withdrawal users (who were not nsASTR holders) will receive 100% reimbursement directly via the claim page.
  • Fraud control
    • Most LP positions were out of range, preventing large-scale arbitrage or malicious accumulation of underpriced tokens. As a result, no significant malicious purchases of nsASTR or nrETH at discounted prices were detected on the open market.
    • Addresses identified as malicious through pattern analysis may be excluded from the refund process or have refunds limited.

9 Equitable loss distribution

  • Direct holders, DeFi users, and LPs all receive proportional refunds.

10 Snapshot for Phase 2

  • Contract records each burn amount to determine long-term profit shares.

Phase 2 – Long-Term Recovery via dApp-Staking Rewards

1 No new LSTs until trust restored

nsASTR v2 / nrETH v2 launch only after secure key management instructed by zeroShadow team and trust restored.

2 Secure ownership transfer

  • Revoke old keys; assign control to a new Neemo multisig.

3 Direct staking via Astar portal

  • Users stake ASTR directly to Neemo dApp through the official portal.

4 Collection of dApp-staking rewards

  • Neemo receives daily rewards.

5 Monthly redistribution

  • 100 % of rewards—minus minimal operating costs—are forwarded each month until pre-hack exchange rates are met.
  • Additional funding sources from Neemo Finance (new protocol revenue, additional asset secured by the hacker) will also be funnelled to the pool.

6 Reward splitting buckets

  • X % to nsASTR cohort, Y % to nrETH cohort (exact split).

7 Eligibility

  • Only addresses that completed Phase 1 conversion participate.

Compensation Model

Model Allocation to nsASTR holders Allocation to nrETH holders Estimated Discount
1. Asset-linked (Burn Model) 100% of protected ASTR 100 of returned ETH nsASTR ≈ 21.7, nrETH ≈ 30.5%
2. Split Model (Burn Model) Protected ASTR + 50 % of the 91.634 ETH 50 % of the 91.634 ETH nsASTR ≈ 21.72 % (partly offset by 45.82 ETH in ASTR value), nrETH ≈ 67.6 %
3. Unified pool model (Burn Model) ASTR + ETH combined and redistributed pro-rata by each token’s loss ratio Same pool & ratio Same discount rate for both tokens
4. Snapshot model Protected ASTR only to nsASTR wallets (no DeFi portion in Phase 1) Returned ETH only to nrETH wallets (no DeFi portion in Phase 1) -

Key Concerns with Model 4 (Snapshot model)

  1. High implementation risk – Mass address matching and manual checks are time-consuming; any calculation error is potentially fatal.
  2. Uneven treatment – The majority of nsASTR / nrETH exposure sits in DeFi positions; a pure snapshot would over-reward passive holders and vault users while under-compensating active DeFi users.
  3. No repayment incentive – Borrowers in lending pools could walk away, leaving pools locked and both ASTR and nsASTR withdrawals frozen.

Because of these drawbacks, Snapshot-Only is documented for completeness but is not recommended for adoption.

Pre hacked rate

  • nsASTR to ASTR: 1nsASTR = 1.11 ASTR (1111140869673869707 wei)
  • nrETH to ETH: 1 nrETH = 1.071 ETH/eETH (1071244487797111152 wei)
    • ※ Note : 1 ETH == 1 eETH

nrETH

  1. Current supply : 200,106.92 nrETH
  2. Supply before hack : 106.92 nrETH
  3. Hacker minted amount : 200,000 nrETH
  4. Hacker current amount : 199,975 nrETH
  5. Hacker used amount in attack : 25 nrETH
  6. Supply after cleanup (burning hackers current holdings): 131.92 nrETH
  7. Current eth holding (returned) : 91.639 ETH

nsASTR

  1. Current supply : 358,375,104.425 nsASTR
  2. Supply before hack : 158,375,104.425 nsASTR
  3. Hacker minted amount : 200,000,000 nsASTR
  4. Hacker current amount : 154,000,000
  5. Hacker used amount in attack : 46,000,000
  6. Supply nsASTR after cleanup (burning hackers current holdings): 204,375,104.425 nsASTR
  7. Current ASTR holding (protected) : 204,283,546.036 ASTR
  8. Chunk1 amount: 26,783,546.036 ASTR
  9. Amount used for compensation: 177,500,000 ASTR

Next steps

  • Discussion and decide the compensation model on the Astar forum
  • On-chain vote after the discussion
  • Upon community approval, the fund will be transferred to the Neemo multisig wallet
  • Deploy reimbursement contracts and start the refund process

Conclusion

We sincerely apologize for the situation that has unfolded. If the community grants its approval, we will be able to begin issuing refunds promptly, and subsequent Neemo-generated rewards will continue closing the remaining gap over time. For the sake of every affected holder, we respectfully ask for your consideration and support.

7 Likes
2

Sake’s Astar pool
How will the borrowing portion be handled, and how will it be handled if it’s not a Looping strategy and it’s manual borrowing?

2 Likes
3

nsASTR will be used for ASTR redeem, so once the Sake pool is open, please withdraw your nsASTR and proceed with the ASTR claim

4 Likes
5

Some questions regarding this:

  1. Is the treatment the same for the Soneium network as for the native Astr network?
  2. In terms of time, are we talking about months or years? What is the team’s estimate for recovering the investment?
  3. Was there no support obtained from Soneium or Astr to provide a higher recovery rate, so that instead of investors bearing the recovery time, it would be shared by Soneium or Astr? Why not request a loan and repay it with the rewards?
4 Likes
6

Just because something sounds good doesn’t mean it’s the right and fair thing to do.

2 Likes
8

Appreciate the detailed recovery plan and the transparency so far. That said, I think it’s important to point out a key concern: the current proposal shifts much of the long-term risk onto Astar and the affected users, especially if Neemo’s dApp loses support or underperforms in the future.

To show real accountability, it would be more responsible for Neemo to secure a loan or upfront funding to fully reimburse users now, then repay that through their future dApp revenue. This would avoid placing the financial burden on the Astar Network and provide more certainty for impacted users.

Looking forward to seeing this discussed further.

11 Likes
12

Thank you for the reimbursement plan.

Could you please explain from what perspective you consider “1. Split Model” to be fair and equitable?
I understand that options 2 and 3 were proposed based on different interpretations of fairness and equity, but I couldn’t grasp the reasoning behind option 1.

  • If the goal is to treat nsASTR and nrETH separately, then the “2. Asset-linked model” seems more fair.
    The 91.634 ETH returned by the hacker originally came from stolen nrETH (weETH), so it should be returned to nrETH holders.
  • If you mix it with nsASTR, then option 3 seems more appropriate in terms of fairness.

In the Split Model, 50% of the ETH is allocated to compensate nsASTR holders, resulting in around a 70% discount ratio for nrETH holders, while nsASTR holders receive only about a 20% discount.
I struggle to see how this can be considered fair from any perspective.

Most victims of the exploit are simply hoping to minimize their losses, and some may advocate for proposals that reduce their own losses under the pretense of fairness. I can understand that.
But, the total supply of nsASTR is more than 10 times that of nrETH, and the number of holders is likely far greater as well. Moreover, since this is the ASTR Forum, I assume the majority of participants are ASTR holders.
I’m genuinely concerned that the vote results might end up unfairly biased against nrETH holders due to sheer numbers, at the expense of actual fairness. (I hold both nsASTR and nrETH.)

On a separate note, I also hold yayASTR.
How will reimbursement for yayASTR be handled?
Should users redeem yayASTR for nsASTR first and then follow the same reimbursement process?

3 Likes
14

In my previous post, I did not suggest grouping all losses together.

  • If nsASTR and nrETH are to be treated separately, then the returned ETH should also be returned to nrETH holders ( = Option #2: Asset-linked model).
  • If the returned ETH is to be used to subsidize ASTR losses, then ASTR should also be used to subsidize ETH losses ( = Option #3: Unified pool model).

So, personally, I don’t see “Option #1: Split Model” as a viable approach.
— That is my view.

1 Like
16

My take is asset linked model is better than other models.
I hope you’ll move on the voting session asap.

1 Like
17

Is the refund plan the same for those who used Nemo-Astr-bank in untitled bank??

1 Like
18

The pre-hack was 158,375,104.425 nsASTR and the current ASTR holding is 204,283,546.036 ASTR. 158,375,104.425 nsASTR x 1.11 ASTR = 175,796,365 ASTR should be enough to make up the full amount, why not do it?

3 Likes
19

Why is there no such option for those who only had nASTR without running it on other Dapps, which I think should be returned 100% immediately?

Also, who decided to be a candidate for this option?

3 Likes
20

First of all, note that the following answer is my personnal POV and i do not speak in the name of the ACC.

Thank you for the detailed explanation and ongoing efforts to resolve this situation.
However, I must clearly and firmly oppose split model (option 1) and unified compensation pool model (option 3) but support an Asset-linked model (option 2) for the following reasons:

As I have stated clearly in previous messages on Discord:

Thank you for your update and for the ongoing efforts to address the incident. However, I must be very clear regarding the 200M ASTR transferred to the Astar treasury:

These tokens are not Neemo’s assets, nor are they yours to allocate as you see fit. They belong to users who staked their ASTR through the Neemo protocol, and therefore must be returned to their rightful owners in full—without delay or condition.

It’s also important to emphasize that the vast majority of those ASTR were already in the process of being unstaked prior to the hack, and were only a few blocks away from being released and returned to their rightful owner. Logically and ethically, this makes it obvious that the first step in any compensation plan must be the immediate refund of all pending ASTR withdrawal requests that were interrupted. Fulfilling this obligation is not optional—it is the baseline.

If the current treasury cannot fully cover all affected ASTR holders at once, then securing a loan or alternative temporary liquidity is not just an option—it is a mandatory step. Immediate, one-to-one restitution of ASTR is the only acceptable course of action to preserve user trust and fulfill your responsibility to stakers.

As for the ETH losses, they must be addressed separately. They are a consequence of operational lapses and must be covered by Neemo’s own resources, revenue, or investor support. It would be entirely unacceptable to use user-owned ASTR to cover losses in a different asset class caused by internal security failures.

I urge you to respect user ownership rights and handle this situation with the transparency and accountability it demands. Thank you for your immediate attention to this matter.
source

And further emphasized:

To be very clear, my point is not to suggest prioritizing only the pending withdrawal requests and leaving the rest of ASTR holders with partial coverage. On the contrary — my position is that all ASTR holders should be refunded fully, at the last nsASTR/ASTR ratio before the hack, without any discount or reduction, regardless of whether they were in the withdrawal queue or not.

This is because ASTR tokens staked through Neemo are user-owned assets, not protocol-owned funds. They must be treated as deposits to be returned in full, exactly as they were entrusted to Neemo.

Furthermore, ETH losses should be addressed separately. Compensation for ETH should come from Neemo’s own resources, protocol revenue, or external funding — but never by using ASTR tokens belonging to users. Mixing these compensation pools would effectively make ASTR stakers bear the losses caused by security issues that are not their fault, which is unacceptable.

If the protocol currently lacks sufficient liquidity to restore all ASTR balances immediately, then taking a loan (even at significant cost) is not just an option — it is a necessary step to uphold trust and fulfill your obligations to ASTR stakers. The same requirement applies to ETH: if needed, Neemo must secure additional funding or loans to ensure full compensation to ETH holders as well, without shifting this burden onto ASTR assets.

Thank you again for your continued efforts. I sincerely hope Neemo can implement a solution that respects all user ownership rights and restores confidence in a fair and transparent manner.
source

The ASTR tokens staked through Neemo are user-owned assets, not protocol-owned funds. These tokens already have owners and must be returned to them fully with incurred APR, without discount or reduction. This applies to all ASTR holders, whether or not they were in the withdrawal queue before the hack. For this reason, mixing the compensation pools for ASTR and ETH would be fundamentally unfair.

Furthermore, ETH losses, resulting from Neemo Team’s failure to secure their admin key, must be addressed separately using Neemo’s own resources, protocol revenue, external funding, or loans. Using user-owned ASTR tokens to compensate for ETH losses forces ASTR stakers to bear the cost of a security breach they did not cause, which is unacceptable. It is the protocol’s responsibility to bear accountability and find a way to refund the missing ETH, not with ASTR holder’s property.

It is also critical to highlight that losses in ETH are substantially greater than those in ASTR. The Astar team successfully froze and secured staked ASTR assets, mitigating damage to ASTR stakers and related protocols. Unfortunately, such protective measures were impossible with nsETH, resulting in far more significant losses to ETH holders and other protocols due to ETH loss and abusive nsETH usage. Therefore, using ASTR to compensate for part of ETH loss though a unified pool would put more weight on ASTR users’ contribution than ETH’s. This fundamental difference in loss exposure must be recognized and respected in any compensation plan. In the same fashion, using ETH to compensate ASTR holders would also be unfair for ETH holders.

If the protocol lacks immediate liquidity to fully reimburse all affected nsASTR & nsETH holders, securing loans or alternative funding is not optional — it is mandatory to uphold obligations and preserve confidence.

In conclusion, the unified pool model and split model violates fundamental ownership rights, unfairly redistributes losses and undermines user trust. A segmented compensation approach i.e. the Asset-linked model — ensuring full, immediate restitution of ASTR and most of ETH with available tokens, which can be completed by a team loan, is the only fair, transparent, and responsible solution.

Finally, the proposed compensation plan lacks accountability. The hack was caused by the team’s negligence in securing their admin key, yet it seems that there is no plan to take a loan to immediately cover the missing funds. Instead, the plan appears to rely on dApp staking rewards and protocol revenue to refund the shortfall over time. This exposes users to the risk of loss if the dApp becomes unsupported or delisted. Furthermore, it means Astar Network itself, not Neemo, will ultimately provide a significant part of the financial burden to repay lost funds. Both scenarios are unacceptable as they shift responsibility for the team’s failure onto the community and the network in addition to the reputational damage already incurred by both Astar and Soneium. I thus expect the Neemo team to take full responsibility and put, if needed, all their belongings on the line to secure the required loan to refund users entirely from the get-go and refund their debt though their upcoming revenues.

13 Likes
21

If data mentionned bellow include all lost related to nsASTR, incuding all token lost through miss usage of nsASTR on other protocol, then the 204M should be indeed enough to refund immediatly 100% of the ASTR to users.

Note however, that the 204,283,546.036 ASTR include the 26,783,546.036 ASTR from unstake Chunk1 while the 158,375,104.425 nsASTR do not, as to redeem your ASTR from nsASTR you need to burn you nsASTR first then wait for the unlock of your ASTR which occurs 10 days after the start of the following voting period.

So in total, if all lost involving ASTR are included, they need 202 579 911,900 ASTR which is still 1 703 634,088 ASTR less than the 204,283,546.036 ASTR securred in the Astar treasury. Remaining, which is most probalby protocol owned - TBC - could then be redirected to ETH refund if they want to use it this way. but again, only if the team can prove ownership of those ASTR

Please do not consider this post as, recalculated later in the discution by @you425 (here), I forgot to consider the 1. Supply nsASTR after cleanup (burning hackers current holdings): 204,375,104.425 nsASTR which lead to an actual shortfall of around 50M astr to be able to repay fully all ASTR. Sorry for the missleading answer


9 Likes
22

This is really make sense.
:man_bowing:

23

Thank you for your hard work in refining and presenting the compensation plan.

I have a few questions, but before getting into those, I would like to express my strong preference for the Asset-linked model. The other two options ultimately place the burden on one group of token holders or the other, and I don’t believe that will lead to a good outcome.

Now, my questions mainly concern nsASTR and ASTR:

Looking at these figures, it seems that based on the pre-attack supply of nsASTR, it should be possible to redeem 100% using the ASTR recovered. However, in reality, it is being said that the amount is not sufficient for full redemption of ~204M nsASTR.

This point needs a clearer explanation.

I assume this is likely due to the inclusion of users who were providing liquidity in DeFi and, because of AMM mechanics, ended up holding large amounts of nsASTR through LP tokens. By excluding only the nsASTR currently held by the hacker address and treating all other nsASTR as redeemable, the outstanding debt (around 46M nsASTR) naturally increases.

In most incidents of this kind, compensation is typically based on a snapshot from before the attack. Does this mean that Neemo has intentionally decided not to follow such a snapshot-based compensation plan in this case?

Of course, I understand that tracking this would be extremely difficult. But either way, a more detailed explanation is necessary here.

This amount appears to be around 30M less than the ASTR recovered. Was this difference intentionally excluded for operational purposes?

This also requires clarification.

Depending on how compensation is structured, the community may be able to support the shortfall in ASTR.
For example: “The treasury could loan ASTR to Neemo to cover the shortfall in nsASTR redemption. Neemo would then repay the treasury with priority and potentially offer future token allocations as well.”

However, this would require initiating compensation under the Asset-linked model, and it would also need to be approved through on-chain governance.

There is certainly room for discussion here, but first, we need sufficient clarification from Neemo and a firm decision on the compensation model.

15 Likes
24

If someone supplied both ASTR and nsASTR as collateral on Sake Finance and used that position to borrow nsASTR, how will the compensation plan account for these types of complex, leveraged positions?
Specifically, will directly supplied ASTR (that wasn’t converted to nsASTR) be eligible for reimbursement, or is compensation only for nsASTR-related positions?
And for users who supplied both assets and then borrowed nsASTR against them, how will the net eligible compensation amount be calculated?

1 Like
26

Hi Astar Community,

Sharing my two cents here as one of the members of the Astar Main Council who was directly involved in protecting the 200M ASTR tokens during the recent incident.

Thanks to the swift actions of the Astar Collective, the community, and the Main Council, we were able to block the attempted theft of approximately 26.78M ASTR and 177M ASTR by the attacker. These tokens were not “recovered” after being stolen, they were successfully protected before being taken, and as such, they should not be considered part of the compensation pool.

These funds should return to their rightful owners: nsASTR holders who held the tokens prior to the incident.

Additional Context on Unstaking:

There are two distinct chunks of unstaked ASTR:

  1. ~26.78M ASTR – Unstaked as part of Neemo’s normal operations before the incident.
  2. ~177M ASTR – Unstaked by the attacker during the exploit.

These should be treated separately:

  • The 26.78M ASTR should first be returned to the nsASTR holders who had already burned their tokens before the incident.
  • The remaining 177M ASTR can be sent to the contract to allow current nsASTR holders to burn their tokens and redeem their ASTR accordingly.

On the Compensation Options:

  • Option 2 seems like the most appropriate path given the current circumstances.
    However, it doesn’t yet address the broader damage to the DeFi ecosystem on Soneium. Protocols like Sake Finance and UB are currently experiencing bad debt, preventing users who deposited nsASTR from withdrawing.
    I strongly believe Neemo should include this in their compensation plan as a second phase.

  • Option 3 should be off the table.
    As stated earlier, the 200M ASTR were protected, not recovered, and therefore should not be treated as compensatory assets for the Neemo exploit.
    Additionally, compensating nETH holders with ASTR could create immense sell pressure, as many would likely dump ASTR to recover ETH, something we cannot accept as a community committed to Astar’s long-term value.

I encourage Neemo to listen to the community’s feedback and address the concerns raised. While there may not be a perfect solution that satisfies everyone, the 200M ASTR are held by the on-chain treasury, and thus any action involving them will require community consensus through governance.

Gaius_sama
Astar Main Council & Core Team :astr:

21 Likes
27

this would definitly revive the trust of the community if by any means they fully reimburse users now rather than through months

1 Like
28

Regarding this hack, I hope that the tokens I deposited will be returned to me, even if it takes time.
Also, the redemption procedure should ideally be automatic, with no action required on the user’s side to prevent forgetting to collect.

1 Like