The Simple Version

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.

What We Did Right

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.

What We Did Wrong

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 Timeline: How It Unfolded

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.

Why This Happened

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.

The Bigger Lessons

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.

What We're Doing Now

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.

The Bottom Line

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 are providing a comprehensive technical post-mortem regarding a sophisticated smart contract vulnerability that was exploited in our recently deployed Base contract.

This incident demonstrates the critical importance of proper access control implementation in upgradeable smart contracts.

Timeline of Events

Pre-Deployment - Extensive Testing Phase

• Comprehensive testing conducted across multiple testnets including Solana Devnet and Base Sepolia;

• All functionality validated successfully in testnet environments;

• Critical Oversight: Vulnerability present in testnet code but not identified during testing phase;

• Wormhole deployment checklist initiated and followed according to standard procedures.

Day 0 - Initial Deployment

• Base contract deployed at block 34154347;

• Contract deployed with incomplete authorization function: function _authorizeUpgrade(address newImplementation) internal virtual override { }

• All standard deployment procedures followed.

Day 0 - Immediate Exploitation (Within 3 Blocks)

• Attacker gained control of proxy contract through sophisticated Multicall message;

• Transaction trace obfuscated on token contract logs:[
  0xa7db9a1b4960cd51ca8548cd1ee96b4b4892595aae7c22139bd5645560a7f081](https://basescan.org/tx/0xa7db9a1b4960cd51ca8548cd1ee96b4b4892595aae7c22139bd5645560a7f081)

• Exploiter immediately overwrote contract logic, storing malicious implementation in different memory position.

Day 0 - Response Attempts

• Vulnerability identified quickly by our team.

• Emergency upgrade deployed:[
  0x03516957497fa0b40ef14996e0e27fd4647298893cb6616e0f5fd8b0627f7815](https://basescan.org/tx/0x03516957497fa0b40ef14996e0e27fd4647298893cb6616e0f5fd8b0627f7815)

• Fatal Misjudgment: No apparent tampering visible in contract transaction history led team to believe upgrade was safe to proceed.

• Critical Issue: Due to already compromised memory positions, upgrade only appeared successful while still referencing compromised contract.

• The Point of No Return: Contract was already compromised from block 3; our intervention was already too late.

Day 9 - Final Exploitation

• Attacker executed final phase of attack after 9-day dormancy period;

• Upgraded contract to enable unrestricted token minting.

Full transaction history available: Attacker wallet

Technical Root Cause

The vulnerability stemmed from an incomplete access control implementation in our upgradeable contract:

Vulnerable Code:

function _authorizeUpgrade(address newImplementation) internal virtual override { }

Corrected Implementation:

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

The empty authorization function allowed any external actor to upgrade the contract implementation, effectively granting them complete control over the contract's functionality.

Key Technical Insights

1. Proxy Pattern Vulnerability: The attack exploited OpenZeppelin's upgradeable proxy pattern when access controls are not properly implemented.

2. Memory Position Manipulation: The sophisticated attacker overwrote the contract's storage layout, making subsequent legitimate upgrades ineffective.

3. Delayed Execution: The attacker demonstrated patience, waiting 9 days before executing the final exploitation phase.

4. Testing Environment Blind Spot: Vulnerability remained undetected despite rigorous testing on Solana Devnet and Base Sepolia, highlighting the critical need for security-focused auditing beyond functional testing.

5. False Security from Clean Transaction Logs: The absence of visible tampering in transaction history created a dangerous false sense of security, leading to the fatal decision to proceed with upgrades on an already compromised contract.

Critical Lessons Learned

The "Point of No Return" Principle

Once a proxy contract with security vulnerabilities is deployed, it must be considered permanently compromised from the first block, regardless of visible attack activity. Our attempt to "fix" the contract through upgrades was futile, as the attacker had already gained control within 3 blocks of deployment.

The Audit Imperative

No contract is too simple to warrant a professional security audit. The vulnerability in this case was a single missing access control modifier, yet it resulted in complete contract compromise. Development timelines must accommodate proper security review, not the other way around.

Immediate Actions Taken

• All affected contracts have been paused and secured

• Complete audit of all deployments and upgrade mechanisms initiated

• Enhanced testing protocols implemented for all future deployments

• Additional security review processes established

Compromised Contract Assumption Policy

     NEW RULE: Any proxy contract deployed with security vulnerabilities must be      considered PERMANENTLY compromised.

**     NO EXCEPTIONS:** Even with clean transaction history, compromised proxies cannot      be salvaged through upgrades.

**     Verification Protocol:** Before any contract reuse, bytecode verification must confirm      that referenced implementation matches the last known legitimate deployment.

Mandatory Third-Party Auditing

     REQUIREMENT: All smart contracts, regardless of complexity, must undergo      professional security audits before mainnet deployment.

**     Timeline Policy:** Project timelines will be extended as necessary to accommodate      thorough security reviews.

     No Exceptions: Simple contracts are not exempt from this requirement, as this      incident demonstrates.

Enhanced Development Protocols

• Mandatory access control verification for all upgradeable contracts

• Enhanced monitoring systems for proxy contract interactions

• Multi-signature requirements for all contract upgrades

• Comprehensive penetration testing before mainnet deployments

• Bytecode verification processes for all upgrade transactions

Transparency and Accountability

We are committed to full transparency regarding this incident. All transaction data, contract addresses, and technical details are publicly available on the blockchain. We will be implementing comprehensive measures to prevent any similar incidents in future.

For technical questions or additional information, please contact support@edenlayer.com

Contract Addresses:

• Main Proxy Contract: 0xda1d88fd16e1fee9fdf2579a1c41e880b75dde8b

• First Implementation Contract: 0x37388294ac0c50b1303710ee8fbdd9488fad4083

• Attacker Address: 0x49d514983deb11b824a359af247ca2d457cbc593

Edenlayer serves as the Agentic Collaboration Layer, addressing the fragmentation and inefficiencies of the emerging Agentic Economy.

Built on the Model Context Protocol (MCP), the Edenlayer protocol provides an accessible and highly customisable discovery engine that allows AI agents and applications to connect, interact and collaborate.

Through advanced task execution that enables agent-to-agent and agent-to-user interactions, Edenlayer will deliver a dynamic ecosystem where AI-driven services can scale with increased impact. Developers will be able to integrate their agents, expanding potential user base; while users gain access to a range of AI-powered tools and services, all within a unified framework.

As the native token of the protocol, $EDEN will facilitate payments for compute, services and task execution.

$EDEN Contract Address:
5sbZ3E6x84GXtWmBG2vX5pCTLuvCPiwn5C2Yrs3eden

This utility grants Users the ability to better control where they spend their time and money while benefiting from the Agentic Economy; while also incentivising developers to produce Agents and Services that deliver high-quality work.

Edenlayer Solves Key Challenges

At the heart of the Edenlayer protocol is our Mixture of Agents (MoA) architecture, a dynamic task-routing system inspired by the Mixture of Experts architecture used in advanced AI systems.

MoA ensures that tasks are routed efficiently to the most qualified agents based on their expertise, performance and real-time availability. This creates a cost-effective, scalable solution for agent-to-agent and agent-to-user interactions that increases AI utility across sectors.

Edenlayer addresses many issues in the current AI landscape:

• Reduces Fragmentation: AI agents exist on isolated platforms, making discovery difficult for users and limiting developer visibility. Edenlayer unifies these agents within a single registry, allowing for greater interoperability and simplifying access.

• Expands Reach: Smaller teams often struggle to gain global visibility. Edenlayer provides integrated discovery tools to help developers reach broader audiences and expand their market through custom applications that call upon the protocol.

• Increases Monetisation: Many agents lack sustainable monetisation. Edenlayer introduces payment systems that support agent-to-agent and agent-to-user transactions, providing access to more sustainable business models and growth.

• Open Protocol: Edenlayer's open architecture allows anyone to call upon the collective capabilities of the network to create specialised use cases, cross-chain interoperability solutions, smart wallets and white-label AI terminals that meet their own specific needs.

Co-founded by End (ex-Product Lead, TreasureDAO) and Felix Norden (ex-AI Scientist, Twitch/Amazon), Edenlayer is backed by a 10-member team that brings together expertise from Nintendo, Google, Riot Games, IBM, Canva, Neo Tokyo, Ape Terminal, KPR and more.

Edenlayer’s launch marks a major advancement for AI interoperability and accessibility. By creating an open collaboration protocol for AI agents and applications, Edenlayer is setting the foundation for the next wave of automation and innovation in the Agentic Economy.

Full Litepaper: paper.edenlayer.com

$EDEN Contract Address:
5sbZ3E6x84GXtWmBG2vX5pCTLuvCPiwn5C2Yrs3eden

www.edenlayer.com
@Edenlayersupport
@edenlayer.com

$EDEN is the fuel of Edenlayer, facilitating micropayments for computing, storage and agent-to-agent task execution in our open protocol for AI collaboration.

Full details about the Edenlayer protocol and how it functions, as well as $EDEN tokenomics and the team, can be found in our Litepaper: https://paper.edenlayer.com

We’re excited to take part in the Web3 Agentic Economy. This begins with our waiting list for access to the EDEN IO terminal, as well as a number of other VIP perks and priorities that comes from being an $EDEN holder.

With the launch of the $EDEN token imminent, we are now inviting all those who wish to be part of the launch and first in line as we continue to build Edenlayer.

Early access registration is OPEN NOW and by registering you also enter your application to receive a free allocation of $EDEN tokens that can be claimed during the launch window.

We will be allocating 3% of supply to successful applicants, in equal proportion among those who qualify. These will be available to claim on the day of TGE and will be 100% unlocked.

REGISTRATION PROCESS

To register for early access and the chance to receive an $EDEN token airdrop at launch, you must complete the following:

1. Register your account at https://edenlayer.com/early-access (the higher your % completion, the more chance you have of receiving an airdrop allocation)

2. Follow @Edenlayer

3. Post a comment on what utility you want to see available in the Edenlayer protocol.

IMPORTANT: Make sure to tag @Edenlayer and that your X account matches the one verified with your Edenlayer login. You must have more than 50 followers to qualify.

If you have any support questions please contact us via support@edenlayer.com

$EDEN TOKEN PERKS

This is an opportunity to join us as we launch a new AI-centred project for the next era of Web3. By holding onto your allocation, you will qualify for a wide range of benefits over the coming weeks and months.

Benefits for holding the $EDEN token will include:

• Beta access to the EDEN IO terminal, with priority given based on holding amount;

• First look and early access to new agents, services and utilities as they are integrated into the protocol;

• Priority-tier access to a Keycard battlepass mint for New Eden Dreams, the gamified onboarding platform produced for Edenlayer;

• A range of other benefits and perks from partner projects and agents that become part of the Edenlayer Index.

We are aiming to onboard a new wave into the coming Agentic Economy. To do so, we want to celebrate the launch of our project with the Web3 community and give you the resources needed to join us on the ground floor.

REGISTRATION IS OPEN!

Early access registration is now open. We will announce when registrations are closing in advance, but expect the window to be short depending on demand.

We will message successful applicants via email, using the details provided when you register your Edenlayer account. $EDEN tokens will be available through a secure airdrop claim portal on launch day.

If you have any questions or technical issues, please email support@edenlayer.com and someone from the team will respond as soon as possible.

All applicants are responsible for understanding and complying with their own local regulations and tax-implications of receiving a token airdrop, which will vary depending on geographic location.