dApp Staking Temporarily in Maintenance Mode Due to Neemo Finance Incident

Astar
46

@Maarten

Can you explain the root cause of this hack

No guard rails for projects to follow. Not that hard to state that each project needs to have a multisig. Maybe for LST projects implement that someone from council / AFC or whatever has to verify a multisig exists or has to be a name on it.

The responsibility always falls with those in charge at the end of the day. Blaming others and not taking responsibility in business is a recipe for disaster, and a victim mindset.

You do realise that projects working by themselves (such as Neemo) have inadvertently brought down the Astar Network?

There needs to be a control in place so this can’t happen again?

Or are we just going to blame the next project when they bring Astar Network down?

It’s not even about blame - it’s about creating conditions where this can’t happen again.

Community Council: responsible for the community treasury, paying our agents, UCG, dApp Staking (listing and delisting)

I don’t really see these guys commenting in here. Everyone makes safe comments.

Why am i 1 of 3 people in here actually trying to improve the processes and system? I’m not being paid either and have no financial incentive.

Can you teach me what guideline is missing for anyone to follow?

Just bring in more controls for dApps who operate with a large TVL and can have large impact on the ecosystem.

Why is this being interpreted as a bad thing?

Soon there is a new selection of members in the Community Council and I hope you can apply so you can support dApp Staking and take a more influencing role to change things.

I’m too honest and won’t get in.

I’d cut all of this ambassador funding straight away but that’s a different topic.

But overall there is a big changed needed in the culture here but this is leaning off topic.

Management are outsourcing responsibility and people are putting in minimal effort for inflated rewards.

And this is the situation it culminates in when a disaster happens

3 Likes
47

I’m ok with this. So lets do it.
We can vote ‘no’ to this Urgent Proposal: Secure Custody of Neemo dApp Staking Funds, Ownership Transfer & Reactivation of dApp Staking to enable dApp Staking again and first check all LST projects. Just a note: Astar Network is not down, dApp tTaking is paused but not down.

Lets ask community council to check all projects on dApp Staking. Ask multisigs, KYB, etc… in this case Astar can’t be blamed to offer a decentralized network where everyone is free to build.

2 Likes
48

Good conversation - thanks for taking my reply serious to your questions.

Culture starts from the top and feeds down to everyone else.

I’m just a user at the end of the day.

If i can make you reply passively aggressively like this, then something is not right.

(This comment is respectful and not violating any rules before i get hit with that)

1 Like
49

I feel you don’t understand my position.
I received the call on Sunday morning 6AM about a hack on Neemo, organized the full war room to ensure all users on Astar L1 funds are safe and we succeeded. We had all ‘Astar Core’ members awake and working on this for the whole Sunday morning. Supported Neemo to prepare their community messaging and next steps. What are the solutions, and guided them. Ensure clear community with Sony and all stakeholders that Astar wasn’t behind this hack and is secure and operating without any issues. Talk with all VCs that invested in ASTR that Astar Network has no brach and security issue is on a project, not on the network that the Foundation controls.

When we did everything to secure Astar L1, Astar Foundation is target as one to blame because of this hack and not have done DD on a project in another ecosystem that offered ASTR LST in that ecosystem. We also recently opened and deployed ASTR on OP and Ethereum to adopt and have project work with ASTR. Astar Foundation might need to close again those lanes to ensure a more secure use of ASTR. I feel that Astar Foundation work is not appreciate enough when we are doing things right.

8 Likes
50

I’m not doubting the work you do.

I feel my message is being lost in the paragraphs.

In order for you and the core team to not be in this situation again, i am suggesting simple controls to be implemented.

No1 wants to be having to explain to investors and partners about these situations.

There is no system security breach but there is a gap in the processes.

I work in this stuff for a career.

Edit : if someone messes up in a workplace, you don’t blame the person, you blame the process.

CAPA’s (correction action preventative action) exist for a reason (i assure you Sony uses these) Technically everything is outstanding but we are being hit with the processes and procedures which is clearly a weakness

IMG_5812
IMG_5812828×774 136 KB

2 Likes
51

I can assure you that you expose the concepts in an exemplary way, I share your thoughts, I believe there is little to object if you aim for the good of Astar. Beginning to admit that, perhaps, there was “lightness” is certainly a solution to the problem itself.

2 Likes
52

Thanks @TheRealisildur

It’s worrying because if Sony ask:

“Ok what’s being done so this doesn’t happen again?”

And Astar reply with:

“Well, it’s an underlying dApp external to Astar network so it’s not our responsibility”

We are absolutely cooked in terms of a partnership.

This type of response signals it will happen again.

If one of my prospective partners or outsourcing vendor said this i would cut them off instantly. Huge organisations don’t give a f**k about blame - they want risk eliminated and management to take responsibility so that it can’t happen again..

Sony and the communities all view Astar as 1 entity and the optics don’t care if this is correct or fair.

Optics and perception is reality - especially in the world of business.

2 Likes
53

If thats your worry, I can say they dont think like this or dont ask those questions, they understand how web3 works and decentralization. Our partnership is not hurt because of this becuase it was well managed by Astar Foundation.

They are more worried about a hack happened on their ecosystem then the asset related to the hack. The hack wasn’t on Astar or the ASTR token itself, it was a hack on a smart contract with a compremised wallet that they have on their blockchain.

I’m not worries about Sony, I’m more worried that sentiment is in making Astar more centralized. If thats the direction, I’ll work on proposing a full DAO activation so Astar keeps in hands of everyone instead of one organization.

1 Like
54

I’m not worries about Sony, I’m more worried that sentiment is in making Astar more centralized. If thats the direction, I’ll work on proposing a full DAO activation so Astar keeps in hands of everyone instead of one organization.

I would welcome the discussion around this.

If you believe Astar is mature enough for this then why not.

But the fact we have a sudo key and had to use it already this year for another incident, and having to freeze dApp staking to stop this issue escalating, means we’re probably not there yet.

But you are one of our leaders so i trust in your opinion

Edit: and by sentiment do you mean 2 or 3 users? Because no1 else is commenting or giving any opinion or suggestions.

55

Over the past few years, we’ve been working toward making Astar a decentralized and permissionless blockchain, aligned with the core ethos of public blockchains. This includes implementing decentralized governance for core and technical updates, and gradually opening governance to the broader community and stakeholders through councils.

Reading your posts, however, it seems you’re asking us to do the opposite, turning Astar into an extremely controlled environment where the Astar Foundation would be responsible for all developers, contracts, and dApps building on the network. But how can Astar be considered decentralized if, at the end of the day, the Foundation has absolute control over every dApp, contract, and product on the platform?

Frankly, no one wants to build on a blockchain that centralized and tightly controlled. Not to mention, maintaining that level of oversight would require a massive team to monitor every project in detail, with deep technical knowledge. That simply isn’t feasible.

This approach contradicts Astar’s vision as a collective.

Yes, we can improve due diligence processes and introduce better security practices. But ultimately, we do not have access to the internal architecture or sensitive permissions of every dApp. A team could say one thing and do another, and since we’re not an auditing firm, we can’t guarantee a project’s internal security setup.

In Neemo’s case, our due diligence focused on the team, their experience, backers, project design, GMT, and contract audits. But we don’t, and can’t, have insight into how their admin EOA keys are stored. That’s beyond our scope. See here for Neemo Finance full audit scope that we used for our DD: Neemo Finance audits by Hacken

As Maarten pointed out, the incident occurred on Soneium and was caused by human error, not a smart contract or blockchain failure. The project happens to use ASTR, but the same mistake could’ve happened to any DeFi project, on any chain. Should we blame Soneium? Sony? Optimism, since Soneium uses the OP stack? Ethereum, since it’s an L2?

It’s always easy to point fingers, especially in difficult moments. But while some were quick to criticize, we spent our Sunday actively working on damage control and recovery. Personally, I had other plans, but I dedicated my day to this, and thanks to our swift action, we were able to save 200M ASTR from the exploit. That seems to be overlooked in this conversation, as if we weren’t also affected, despite being major stakeholders and Neemo users ourselves.

If the community wants tighter control, then let’s not claim we’re pursuing decentralization. You’re welcome to propose a governance change, but I personally wouldn’t support it.

That said, this thread is about putting dApp Staking into maintenance mode. If you’d like to debate who is responsible for what or discuss broader accountability topics, please open a separate thread. Let’s keep this discussion focused on how we can re-enable dApp Staking safely and effectively.

Thank you.

6 Likes
56

@Gaius_sama You’ve misread my comments completely - i’m blaming the process.

I’m not blaming you / the team for the hack.

I’m trying to prevent future hacks.

I’ve called out high TVL Defi LST projects specifically - we have 3 currently

The fact we’re still centralised has saved us 200M in this circumstance. Users currently can’t withdrew their Astar bro - we’re centralised and it saved us.

I also have no interest in a governance change - that was Maarten suggesting it.

But i’m the bad guy even though we’re using centralised measures as we speak

IMG_5813
IMG_5813828×769 122 KB

1 Like
57

Indeed, the process can, and should, be improved. I completely agree with you on that. What matters now is that we learn from this incident and take the necessary steps to strengthen our systems and prevent similar situations in the future.

That said, in the specific case of Neemo, even if we increase the level of due diligence for dApp Staking, it will never be 100% risk-free. Also, dApp Staking itself is not directly to blame here, any project, whether listed in dApp Staking or not, can choose to build on Astar and launch ASTR LST tokens.

For example, imagine if Bifrost had been affected by a similar exploit. The situation could have been fundamentally the same in terms of user impact, yet it wouldn’t have been linked to dApp Staking at all. Bifrost is a major LST provider but is not part of the dApp Staking program. If their contract architecture had a vulnerability and an attacker managed to unstake and withdraw large amounts from their vASTR LST, it would be a serious issue, but not one the Astar Foundation or ACC could have anticipated or prevented through dApp Staking oversight. Bifrost being only a staker in dApp Staking, the outcome would be the same.

My point is: yes, we absolutely must improve our security practices and risk mitigation processes, but no system can offer a 100% guarantee. What we can do is minimize the risk and build stronger mechanisms to detect and respond quickly.

The ACC will share their thoughts on this discussion and provide recommendations for improving due diligence practices. I’ll leave it to them to comment in more detail.

@FFR23 I truly appreciate your involvement and concern for the Astar Network. However, I want to mention that some of your comments could be interpreted as placing blame on the Astar Foundation. That’s difficult to hear, considering the amount of work we’ve put into building a safe and resilient ecosystem. If that wasn’t your intention, I’m glad to move forward together, learning from this event and continuing to grow as a collective.

9 Likes
58

@Gaius_sama

If that wasn’t your intention, I’m glad to move forward together, learning from this event and continuing to grow as a collective

Thanks bro - was not my intention so we are 100% aligned here and in the rest of your comment.

2 Likes
59

I fully agree with what Gaius commented here.

It just so happened that Neemo was participating in dApp Staking, but similar incidents could occur regardless of that. And if we are operating on a public blockchain, it is fundamentally impossible to prevent such occurrences entirely.

Of course, it is possible to set security standards for projects participating in dApp Staking, but in the end, we must rely on trust, and it is not possible to guarantee 100% safety.

If one wants to avoid this kind of risk, the only alternative would be to use a highly centralized private chain, where deployers are required to sign contracts through KYB and users are also subject to KYC. But that is no longer DeFi — it’s essentially CeFi (or TradFi).

Even outside of the Neemo case, there have been many instances where private keys were leaked and tokens were minted maliciously. Ultimately, this is the responsibility of the dApp developers, and no external party can fully control or prevent such issues.

For example, in older DeFi protocols where there are no controlling private keys and contracts are fully decentralized, incidents like this would not happen — but with the increasing complexity of modern DeFi, that approach introduces its own unacceptable level of risk.

In the end, we are all to blame for lacking proper risk management and only discussing security after something goes wrong. It is up to each user to inquire, understand, and take responsibility when using a dApp. This is the nature of DeFi. If someone finds that unacceptable, they should stick to CEXs.

As for Astar Foundation, I believe they have been doing enough.

2 Likes
60

Everything you say is correct, you leave out just one SMALL detail.
ASTAR for its own gain has always PUSHED and SPONSORED the use of nsASTR, the most used derivative on Soneium.

They should have at least monitored better, asking the various teams for tests, checks etc especially on something as important as the type of private key storage.

61

Yes, that may be true.
However, the stricter we are, the more difficult it becomes to market our products, so it may be difficult to determine the appropriate level of strictness. It is quite difficult to check the security status of all projects that are discussed, and it may cause the organization to become rigid.

Additionally, while there is a strong connection in this case, Astar Foundation and Sony BSL make separate decisions, so it is not something we can fully propose or control.

While I don’t think requiring meticulous attention is inherently wrong, it does feel a bit excessive.

62

:counterclockwise_arrows_button: Update: Recovery Plan for Neemo Chunk 2 (177M ASTR)

Following the successful execution of last weekend’s emergency proposal to secure the first batch of unlocked ASTR (Chunk 1) from Neemo Finance, we are now moving forward with the final step to secure Chunk 2 (~177M ASTR) based on Neemo’s formal request.

This plan has been coordinated with the Neemo team and will follow a similar structure to the previous operation.

:white_check_mark: Recap: Chunk 1 Successfully Secured

We’re pleased to confirm that Referendum #27, covering the withdrawal and safeguarding of Chunk 1 (~26.78M ASTR), was approved by ASTR token holders and successfully executed on-chain on Tuesday, July 8.

The funds are now held securely in the on-chain Treasury wallet for safekeeping.

:date: Next Step: Chunk 2 Recovery (177M ASTR)

To recover the remaining ASTR still unlocking in Neemo’s staking position (Chunk 2), we will replicate the same governance process, adjusted for timing and scale.

:wrench: Maintenance Mode – Scheduled for Thursday, July 10 at 7:00 AM UTC

Maintenance mode will be re-enabled through governance referendum to execute the fund recovery process securely.
Estimated maintenance window: 7:00–11:00 AM UTC

:ballot_box_with_ballot: Step 1: Referendum #1 – Maintenance Mode (Today, July 9)

The first referendum to enable maintenance mode ahead of the Chunk 2 fund recovery is now live and open for voting.

:ballot_box_with_ballot: Vote here: Subsquare – Referendum #29

  • Purpose: Temporarily activate maintenance mode for dApp Staking
  • Execution Time: Scheduled for Thursday, July 10 at 7:00 AM UTC
  • Voting Period: Fast-tracked referendum, closes in ~12 hours

This short maintenance window will allow the safe execution of the fund recovery and the reactivation of dApp Staking once complete.

:ballot_box_with_ballot: Step 2: Referendum #2 – Chunk 2 Recovery (Thursday, July 10)

Once maintenance mode is active, a second referendum will be submitted containing a batch call to:

  1. Disable maintenance mode
  2. Claim the unlocked funds
  3. Force transfer ~177M ASTR to the on-chain Treasury wallet
  • The referendum will be fast-tracked, with a 2-hour voting period starting at 9:00 AM UTC and execution by 11:00 AM UTC.

:bullseye: Expected Outcome (Thursday by 11:00 AM UTC)

  • ~177M ASTR (Chunk 2) will be securely transferred to the on-chain Treasury wallet
  • dApp Staking will resume normal operations
  • No further access to compromised Neemo addresses will be required

This process ensures a clean, secure, and final resolution to the Neemo recovery effort using on-chain governance and minimizing risks.

:raising_hands: Next Steps & Community Support

We’ll provide real-time updates when:

We thank the community for their rapid coordination and continued support in resolving this matter through governance.

Astar Foundation

5 Likes
63

Thank you so much to the entire Astar team for your incredible support. We truly and deeply appreciate your swift coordination and continued efforts to help recover Chunk 2.

We are also doing everything we can on our side to ensure full compensation for affected users.

Thank you again.

3 Likes
64

Thank you very much. I can rest assured for now.
I voted.

65

The final referendum in the Neemo recovery plan is now live and open for voting:

:link: Vote here: Urgent Proposal: Recover Neemo Chunk 2 (~177M ASTR), Transfer to Treasury & Resume dApp Staking

This proposal will:

  • Claim ~177M ASTR (Chunk 2) from Neemo’s dApp staking position
  • Transfer the funds to the on-chain Treasury wallet
  • Disable maintenance mode
  • Resume dApp Staking operations

:three_o_clock: This is a fast-tracked referendum with a 2-hour voting window, so please vote as soon as possible to ensure smooth execution.

:blue_book: Full context: Forum Post – Neemo Recovery Plan

Thank you for your continued support in safeguarding the network and helping bring dApp Staking back online.

Astar Foundation

4 Likes