We want to share the full story of a recent security incident with one of our smart contracts. This is written for everyone (not just developers) to understand what went wrong, what we learned and what we plan to do going forward.

When we expanded the $EDEN token from Solana over to Base, we deployed a smart contract with a security flaw. Within seconds, an attacker took control of it in a way that was not easily detectable. They then waited 9 days before stealing tokens.

Despite spotting the contract issue and deploying a fix, we remained unaware that the attacker was already in control from the beginning.

Thorough Testing: We tested our contract on multiple test networks - Solana Devnet and Base Sepolia. Everything worked perfectly. Our token could be minted, transferred, and all features functioned as designed.

Professional Process: We followed industry-standard deployment procedures, including detailed checklists for our Wormhole integration and spoke to relevant teams on our approach to the launch. We weren't rushing or cutting corners on our process.

Quick Response: When we discovered the vulnerability, we identified it within hours and immediately tried to fix it. We deployed not one, but two emergency upgrades to secure the contract.

The Fatal Flaw: Our smart contract was missing a single line of code: a security check that determines who can upgrade the contract. Instead of requiring permission, our contract let anyone upgrade it.

The vulnerable code looked like this:

function _authorizeUpgrade(address newImplementation) internal virtual override { }

It should have looked like this:

function _authorizeUpgrade(address newImplementation) internal virtual override onlyRole(UPGRADER_ROLE) { }

No Security Audit: Our biggest mistake was that we didn't have a third-party security expert review our contract before deployment. We thought our testing was sufficient, but testing for functionality is different from testing for security vulnerabilities.

Misunderstanding the Threat: When we tried to fix the contract, we thought we had succeeded because our updates appeared to work and there was no sign of anything compromised. What we didn't realize is that the attacker had already rewired the contract's internals, so our ‘fixes’ were just cosmetic.

The Deployment We deployed our contract and within 3 transactions, a sophisticated attacker spotted our vulnerability and took control. They did this so quickly and quietly that there was no obvious sign of the attack.

The False Hope We discovered the vulnerability the same day and immediately deployed fixes. Our emergency upgrades seemed to work and the contract accepted our changes. We checked the transaction logs and everything looked normal.

The Hidden Truth What we didn't know was that the attacker had already changed how the contract's upgrade system worked. Our upgrades were being applied to a fake version while the real control remained with the attacker.

The Final Strike The attacker waited 9 days, likely to see if the token would appreciate in value. They then gave themselves unlimited power to mint tokens and sell them on market.

Testing Isn't Security: Our extensive testing proved the contract worked as intended, but didn't catch this security flaw.

Smart Contracts Are Unforgiving: Unlike traditional software, smart contracts can't be easily patched once deployed. If there's a security flaw, attackers can often exploit it faster than developers can fix it.

Complexity Breeds Vulnerability: Our contract used an "upgradeable" pattern that allows improvements after deployment. While powerful, this system creates additional attack surfaces that require extra security measures.

Assume the Worst: If a smart contract is deployed with any security vulnerability, it should be considered permanently compromised. Even if you don't see any attacks, assume they've already happened.

Audit Everything: No smart contract, no matter how simple, should go to production without a professional security audit. Development timelines must accommodate this - security cannot be rushed.

Verify Before Trusting: Before reusing any potentially compromised contract, the underlying code must be verified to ensure it matches what you expect. Clean transaction logs don't guarantee safety.

Immediate Changes

• All affected contracts have been secured;

• New mandatory audit requirements for all deployments;

• Enhanced verification procedures for all upgrades.

New Policies

• Any contract with vulnerabilities gets completely rebuilt, never patched;

• Professional security audits required before any mainnet deployment;

• Multiple verification steps before any upgrade operation.

We made an avoidable mistake: we focused on making our contract work without ensuring it was secure on all fronts. One missing security check led to complete compromise. Our sophisticated attacker exploited both our technical vulnerability and our human assumptions about how attacks work.

This incident cost us money, credibility and, even worse, it hurt our community that supports the project. It also taught us invaluable lessons about smart contract security. We're sharing this story openly because the crypto space only gets safer when we all learn from each other's mistakes.

Taking on board everything we have learned through being attacked in this way, we are implementing comprehensive changes to prevent it from ever happening again.

Despite this setback, our product development continues as planned and we will be sharing more updates on that front in the near future.

If you were affected by this exploit and held $EDEN tokens on Base chain, please join the Edenlayer Discord for information on next steps.

For technical details and transaction information, see our detailed incident report here.

We want to share the full story of a recent security incident with one of our smart contracts. This is written for everyone (not just developers) to understand what went wrong, what we learned and what we plan to do going forward.

When we expanded the $EDEN token from Solana over to Base, we deployed a smart contract with a security flaw. Within seconds, an attacker took control of it in a way that was not easily detectable. They then waited 9 days before stealing tokens.

Despite spotting the contract issue and deploying a fix, we remained unaware that the attacker was already in control from the beginning.

Thorough Testing: We tested our contract on multiple test networks - Solana Devnet and Base Sepolia. Everything worked perfectly. Our token could be minted, transferred, and all features functioned as designed.

Professional Process: We followed industry-standard deployment procedures, including detailed checklists for our Wormhole integration and spoke to relevant teams on our approach to the launch. We weren't rushing or cutting corners on our process.

Quick Response: When we discovered the vulnerability, we identified it within hours and immediately tried to fix it. We deployed not one, but two emergency upgrades to secure the contract.

The Fatal Flaw: Our smart contract was missing a single line of code: a security check that determines who can upgrade the contract. Instead of requiring permission, our contract let anyone upgrade it.

The vulnerable code looked like this:

function _authorizeUpgrade(address newImplementation) internal virtual override { }

It should have looked like this:

function _authorizeUpgrade(address newImplementation) internal virtual override onlyRole(UPGRADER_ROLE) { }

No Security Audit: Our biggest mistake was that we didn't have a third-party security expert review our contract before deployment. We thought our testing was sufficient, but testing for functionality is different from testing for security vulnerabilities.

Misunderstanding the Threat: When we tried to fix the contract, we thought we had succeeded because our updates appeared to work and there was no sign of anything compromised. What we didn't realize is that the attacker had already rewired the contract's internals, so our ‘fixes’ were just cosmetic.

The Deployment We deployed our contract and within 3 transactions, a sophisticated attacker spotted our vulnerability and took control. They did this so quickly and quietly that there was no obvious sign of the attack.

The False Hope We discovered the vulnerability the same day and immediately deployed fixes. Our emergency upgrades seemed to work and the contract accepted our changes. We checked the transaction logs and everything looked normal.

The Hidden Truth What we didn't know was that the attacker had already changed how the contract's upgrade system worked. Our upgrades were being applied to a fake version while the real control remained with the attacker.

The Final Strike The attacker waited 9 days, likely to see if the token would appreciate in value. They then gave themselves unlimited power to mint tokens and sell them on market.

Testing Isn't Security: Our extensive testing proved the contract worked as intended, but didn't catch this security flaw.

Smart Contracts Are Unforgiving: Unlike traditional software, smart contracts can't be easily patched once deployed. If there's a security flaw, attackers can often exploit it faster than developers can fix it.

Complexity Breeds Vulnerability: Our contract used an "upgradeable" pattern that allows improvements after deployment. While powerful, this system creates additional attack surfaces that require extra security measures.

Assume the Worst: If a smart contract is deployed with any security vulnerability, it should be considered permanently compromised. Even if you don't see any attacks, assume they've already happened.

Audit Everything: No smart contract, no matter how simple, should go to production without a professional security audit. Development timelines must accommodate this - security cannot be rushed.

Verify Before Trusting: Before reusing any potentially compromised contract, the underlying code must be verified to ensure it matches what you expect. Clean transaction logs don't guarantee safety.

Immediate Changes

• All affected contracts have been secured;

• New mandatory audit requirements for all deployments;

• Enhanced verification procedures for all upgrades.

New Policies

• Any contract with vulnerabilities gets completely rebuilt, never patched;

• Professional security audits required before any mainnet deployment;

• Multiple verification steps before any upgrade operation.

We made an avoidable mistake: we focused on making our contract work without ensuring it was secure on all fronts. One missing security check led to complete compromise. Our sophisticated attacker exploited both our technical vulnerability and our human assumptions about how attacks work.

This incident cost us money, credibility and, even worse, it hurt our community that supports the project. It also taught us invaluable lessons about smart contract security. We're sharing this story openly because the crypto space only gets safer when we all learn from each other's mistakes.

Taking on board everything we have learned through being attacked in this way, we are implementing comprehensive changes to prevent it from ever happening again.

Despite this setback, our product development continues as planned and we will be sharing more updates on that front in the near future.

If you were affected by this exploit and held $EDEN tokens on Base chain, please join the Edenlayer Discord for information on next steps.

For technical details and transaction information, see our detailed incident report here.