Neemo Exploit Reimbursement Plan

Astar
71

Thanks a lot.
You are the one who really doing right thing.

2 Likes
72

I agree with the proposal for compensation based on a pre-hack snapshot, as it seems the most effective approach. If implementing snapshot-based compensation is technically difficult for Neemo, is it not feasible to outsource this process to a third-party institution specializing in blockchain analysis?

3 Likes
73

Hello Neemo team and fellow community members,

Many of us affected by the exploit have complex positions across several DeFi protocols. To ensure everyone—including users of Untitled Bank, Sake Finance, and Sonex—is treated fairly, could you please clarify the following questions?

➤ Untitled Bank and Sake Finance (Lending & Borrowing Protocols)

  1. Netting of Collateral and Debt:
    For users who supplied nsASTR as collateral and borrowed ASTR (especially if the borrowed ASTR was used elsewhere),
  • Will our net eligible balance for compensation be calculated as “supplied nsASTR minus borrowed ASTR,” even if we cannot repay due to LP or protocol constraints?
  • If the post-hack protocol state makes repayment impossible (e.g., all LPs are now nsASTR, no route to recover ASTR), is there a plan to forgive unrepayable debt or to use net exposure at the exploit?
  1. Snapshot and Non-Liquidated Collateral:
  • For positions marked as “not liquidated” by Untitled Bank or Sake Finance teams, but frozen due to protocol pause, how will these be recognized in compensation contracts?
  • If a user’s collateral was at risk or nearly liquidated during the depeg, but support confirms it was not, will the full collateral be counted—regardless of access to underlying tokens?
  1. Bad Debt/Forced Liquidation:
  • For accounts that became “bad debt” due to forced liquidation or protocol failures, will users still receive compensation for the lost value, or is eligibility strictly limited to current protocol balances?

➤ Sonex (LP Protocol)

  1. LP Token Valuation & Claim Rights:
  • How will compensation be calculated for users providing liquidity to ASTR/nsASTR pools on Sonex, especially when pool composition shifted to nearly 100% nsASTR after the exploit?
  • Will LP holders be able to claim based on their underlying nsASTR at the time of the exploit, or only after Tiers 1 and 2 (wallet and lending users) are reimbursed?
  1. Looped and Interdependent Positions:
  • For cases where borrowed ASTR (from Untitled Bank or Sake) was added to Sonex LPs and then the LPs lost liquidity or converted to all nsASTR, how will users trapped in these “loops” be compensated, given they cannot manually unwind?

➤ General (Applies to All Protocols)

  1. Debt Forgiveness and Protocol-Imposed Limitations:
  • Will there be any debt forgiveness or special rules recognizing the impossibility of repaying ASTR borrow due to post-exploit liquidity issues in LPs?
  1. Automatic Handling vs. Required User Action:
  • Will all positions be tallied via protocol data and handled automatically, or are users required to perform specific actions (unwind loans, break LPs, etc.) to qualify for their full compensation?
  1. Transparent Examples and Calculators:
  • Can the team provide practical user-case examples and a compensation calculator for typical complex scenarios (lend-to-borrow-to-LP loops, trapped positions, unrecoverable collateral)?

If you are affected in similar ways on Untitled Bank, Sake Finance, or Sonex, please upvote and comment so we can get full clarification and ensure fair outcomes for everyone with complex DeFi exposure.

Thank you!

2 Likes
74

I may not have fully understood the intent behind your question, so I apologize if this answer doesn’t match what you were asking.

The following is the wallet address that was compromised for nsASTR exploit by the hacker:
0x198b2c4e31186569de4f8058d4871534845bb299

If you check this address on DeBank or similar platforms, you’ll see that after minting 200M nsASTR, the hacker drained funds from various DeFi protocols and swapped them for WETH and USDC.
In total, approximately 99 WETH and 166,027 USDC were bridged to Ethereum.

According to Neemo’s report (the current Reimbursement Plan), it states:
“5. Hacker used amount in attack: 46,000,000”,
so my understanding is that this 46M nsASTR is the number that was converted into the 99 WETH and 166,027 USDC.
This also seems to roughly align with the “shortfall of ~50M ASTR” mentioned in a post in the Forum.

(The ETH stolen directly from the nrETH vault was treated as a white hat action and 80% of it was returned.
However, the ETH drained and described above was sent to Tornado Cash and has not been recovered.)

75

182.6741 ETH + 166,027.12 USDC-91.634 ETH=> (nsAstar+nrEth loss)

nsASTR: Immediate Drain: 4,121,754 ASTR tokens were extracted and bridged to the Soneium chain. These were swapped and deposited into “Untitled Bank” in exchange for ETH, which was bridged back to Ethereum mainnet. LST Minting: 200 million unbacked nsASTR tokens were minted and used to exploit major DEXes and the Untitled Bank protocol on Soneium. These attacks drained further funds. All ASTR funds converted into ETH extracted in this phase have since been deposited into Tornado Cash.

not any possible it’s 46,000,000 loss is count on nsAstar holder

76

Thank you. I understand the suggestion is to calculate each user’s nsASTR holdings based on a snapshot taken prior to the hack. However, implementing this would require renewed coordination with the lending side as well.

There are several concerns with this approach:

  1. Time constraints – This method would require a significant amount of time, and the risk of calculation errors is high and potentially fatal to the process.
  2. Disproportionate treatment – Most nsASTR/nrETH holders are DeFi users. A snapshot-based model would end up disproportionately favoring users who simply held nsASTR/nrETH or were vault depositors.
  3. No incentive to repay – In the lending pools, users have no incentive to repay ASTR. As a result, pools involving nsASTR would effectively become locked, and ASTR/nsASTR withdrawals would be permanently disabled. This affects all users who supplied ASTR.

For the reasons above, we believe that adopting a burn-based mechanism is a more practical and equitable solution than using a snapshot model.

3 Likes
77

With the burn-based mechanism, users can unwind their positions and withdraw their ASTR and ETH.

We have also already coordinated with both Sake and UntitledBank on specific measures to reduce liquidation risk and minimize bad debt.

In contrast, under the snapshot-based approach, the issues mentioned above would apply.

2 Likes
78

The burn of tokens from each hacker address has been completed:

  • 0x198b2c4e31186569de4f8058d4871534845bb299
  • 0x7e9b11d0aa215e0f1a7f62534c7c93fc340d493d
79

So how can this plan already review by Astar team.
Just very different options on each side.

80

Users who simply held nsASTR or deposited in vaults should rightfully receive greater compensation compared to other DeFi users. Neemo has an obligation to return the protected ASTR to those users who hold that right.

1 Like
81

(Sorry, my understanding was wrong. So modifying)

182.6741 ETH + 166,027.12 USDC-91.634 ETH=> (nsAstar+nrEth loss)

The above should be correct, based on the Neemo’s report.
But please refer to my last post regarding nsASTR loss.

Original Post:
Based on the Post-Mortem Report, the following addresses were used in the exploit.
However, the one I posted above (specifically “2. Address that nsASTR was minted to: 0x198b2c4e31186569de4f8058d4871534845bb299”) is just one of them.
So it only accounts for the nsASTR loss, and does not include the nrETH loss.

Attackers Addresses

  1. Address still holds ETH that was obtained by withdrawing weETH, and swapping it into ETH: 0xb750e3165de458eae09904cc7fad099632860b0f
  2. Address that nsASTR was minted to: 0x198b2c4e31186569de4f8058d4871534845bb299
  3. Address that nrETH was minted to (Compromised Address): 0x7e9b11d0aa215e0f1a7f62534c7c93fc340d493d
  4. Address that deposited into Tornado Cash and used it for mixing: 0x4ec65e4dbe6e53ee4938aef2b173b38763d3bc2b

So, if you want to confirm the nrETH losses, you will also need to check the loss on the following addresses:

  1. Address still holds ETH that was obtained by withdrawing weETH, and swapping it into ETH: 0xb750e3165de458eae09904cc7fad099632860b0f
  2. Address that nrETH was minted to (Compromised Address): 0x7e9b11d0aa215e0f1a7f62534c7c93fc340d493d

This is just my understanding, so I might be wrong.

82

@SeiyaChida

The community strongly favors the snapshot model, and for good reason: it ensures that users are compensated based on their original deposited amounts before the hack, not on their current ability to burn assets. Many of us no longer have access to our funds or didn’t move them post-hack, why should we be penalized for that?

The burn-based model unfairly favors users who kept their positions open after the exploit, and it creates a dangerous precedent: lose your funds, and only get compensated if you still have something left to burn.

We ask you directly:
:backhand_index_pointing_right: Are you planning to push the burn-based model through by force, against the clear will of many affected users?
If not, the fair and transparent path is simple:
:backhand_index_pointing_right: Hold a community vote between the two options, snapshot vs. burn.
Let those of us who lost money decide how we want to be compensated.

You say you’re here to help the victims. Then give us a real voice.

Let the users decide, not just the protocol.

3 Likes
83

And to the Astar Team,

My ASTR is currently deposited in the ASTR Vault, which is managed on the Astar platform, not directly by Neemo Finance. This means my funds were entrusted to your infrastructure and ecosystem.

If Neemo proceeds to enforce the burn-based compensation model against my will and against the will of a large part of the affected community, I will initiate legal action in Singapore. This is not a threat, it is a serious and documented step I am prepared to take.

All my transactions, communications, and statements regarding this matter are recorded and timestamped. I explicitly do not give my consent to a burn-based model. I request that you, as the platform provider, take active responsibility in ensuring that user rights and community consensus are respected, especially when funds are locked in contracts on your chain.

We demand a community vote, and your neutral oversight in the process.

Sincerely,

3 Likes
84

I will support that too.

1 Like
85

i will support this matter also

1 Like
86

trully appreciate looking out for defi users and trying to balance it out for everyone thanks for all the support

1 Like
87

@Jack1987
The ASTR vault was used during the pre-deposit campaign for Neemo’s asset management vault.

I’m not sure what you mean by “Astar platform” in this context, but to clarify, the vault was managed entirely by Neemo, not by the Astar platform itself.

We will be moving forward with both the burn-based and snapshot-based options in the upcoming vote.

However, I’d like to respectfully highlight several key concerns regarding the snapshot model:

  1. Time constraints – Implementing the snapshot model would require a significant amount of time, and the risk of calculation errors is high and potentially fatal to the process.
  2. Disproportionate treatment – Most nsASTR/nrETH holders are DeFi users. A snapshot-based approach would end up disproportionately favoring users who simply held tokens or participated in vaults, while disadvantaging more active users.
  3. No incentive to repay – In the lending pools, users would have no incentive to repay ASTR. As a result, pools involving nsASTR would effectively become locked, and both ASTR and nsASTR withdrawals would be permanently disabled — impacting all users who supplied ASTR.

We kindly ask that these factors be taken into consideration during the voting process.

88

I’ve updated the options and will now proceed with preparing the vote.

90

In this context, the ASTR vault should also be considered part of DeFi operations. A vault, by definition, is a place for asset management within DeFi, intended to pursue higher returns.

While no DeFi strategy had been executed yet during the pre-deposit phase, it was clearly intended to be used for DeFi purposes.

91

Over the past week we gathered feedback from the Neemo community, the Astar community, the Main Council, the Astar Collective and the related DeFi protocols. This open forum discussion produced four candidate compensation models. Now we will move to the voting stage. The coming referendum vote invites the community to choose one of those models. We will share the referendum link 07:00 UTC 25 July.

Voting details and next steps

  1. Vote opens 07:00 UTC, 25 July and closes 07:00 UTC, 27 July (48 hours).
  2. Immediately after this vote closes, a second 48-hour referendum will request the Treasury transfer of the protected ASTR to Neemo Multisig.
  3. Claims open – With the burn model, users can start claiming as soon as the vote concludes, whereas the snapshot model requires extensive off-chain calculations and therefore takes significantly longer before claims can begin.

[vote-link]: posted once live

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.

Conclusion

Please review each option and cast your vote. Your choice will determine how assets are distributed; the follow-up referendum will then release the protected ASTR to the contracts accordingly. Thank you for your careful consideration and continued support.

3 Likes