FAQ — User questions following the CrossCurve bridge exploit

Note: This FAQ is for informational purposes only and is intended to clarify the current status and the team’s general steps. It does not constitute legal advice, investment advice, a public offer, a representation or guarantee, or a promise of payments or compensation. The information in this FAQ may be incomplete and/or become outdated. Users should not rely on this FAQ as the sole source for decision making. This FAQ also does not amend nor override the Terms of Service and does not create any additional obligations for EYWA. In case of any discrepancies, the Terms of Service prevail.

Compensation and liability

1. What does the team say to users who lost significant personal savings?

We understand that for some users the lost funds represented a significant portion of their personal savings, and recognize the seriousness of the consequences of this incident. We sincerely regret what happened and approach the situation with the utmost responsibility.

For us, this is not an abstract technical failure, but real losses suffered by real people. That is why transparent communication with users and preventing similar incidents in the future are a priority for the team. We are focused on finding solutions that will help minimize the damage and strengthen the trust of users and partners.

2. Will users’ lost funds be compensated? To what extent and within what timeframe could this compensation take place?

The team is considering the available options for voluntarily supporting users affected by the incident. At this stage, we are analyzing the facts, legal constraints, and technical capabilities, and therefore do not make any promises regarding the specific format, timing, or amount of such support. Any decisions, if made, will be voluntary in nature and will be announced separately after the completion of the review and approval of the relevant internal procedures, and will not be interpreted as an amendment to the Terms of Service or a waiver of the limitations set forth therein.

We are deliberately avoiding making premature statements in order to prevent unfounded expectations and to ensure transparency and feasibility of any parameters.

3. What is the team’s plan if the hacker does not return the funds (after 72 hours or later)?

As mentioned earlier, the team does not build its strategy solely around the scenario of a voluntary return of funds. In parallel to the communication with the attacking party, we are developing an alternative action plan that does not depend on the outcome of the negotiations.

This plan includes technical, legal, and financial measures aimed at protecting users’ interests and minimizing the consequences of the incident. Regardless of whether an agreement on the return of funds is reached, the team will continue working on solutions that allow the project to move forward and fulfill its commitments to the community, presenting our plan within a day after this FAQ is published.

4. What sources will be used for compensation (reserves, funds, future revenue, other)?

At present, the team is analyzing possible sources of compensation in order to form a sustainable and implementable solution. Various options are being considered, including internal project reserves, future protocol revenue, and other mechanisms permissible from financial and legal perspectives.

The final structure of compensation sources will be presented together with a consolidated payout plan. We approach this matter with much deliberation to propose a solution that is not merely declarative and can be executed within the stated timeframes.

5. Does the team acknowledge responsibility for what happened?

We are examining all possible factors, including internal components and interactions with third party services. Certain parts of the infrastructure and services may be provided by third parties; EYWA does not fully control their activities and is not responsible for their actions or omissions to the extent permitted by the Terms of Service and applicable law (including provisions on the use of third party services). We will publish confirmed findings as they become available and within the limits of permissible disclosure.

At the same time, we acknowledge the seriousness of what occurred and aim to respond promptly by verifying facts, strengthening controls, and informing users of the status as information becomes available.

We deliberately and openly speak about the identified vulnerability because our goal is not to conceal the problem but to resolve it. The entire ideology and mission of CrossCurve have always been built around security, and security remains our unconditional priority.

6. Why has the team not yet presented a clear and public compensation plan?

We deliberately did not publish a preliminary compensation plan immediately after the incident in order to avoid unfounded promises and contradictory statements. Forming a compensation plan requires a precise understanding of technical, financial, and legal parameters, as well as an assessment of all possible scenarios.

The team is currently finishing up key stages of analysis. A public compensation plan will be presented immediately after this work is completed within a day of publishing of this FAQ. Based on the results of the analysis, we may publish an update describing the measures taken and, if applicable, the parameters of a voluntary support program. Until an official update is published, any discussions, preliminary estimates, or statements do not constitute a promise of payments, a guarantee of compensation, an acknowledgment of legal liability, or a waiver of the liability limitations set forth in the Terms of Service (including provisions on risks and lack of guarantees).

Technical causes of the incident

7. Why was msg.sender not checked in the contract?

The absence of strict binding to a specific sender address (whitelist) was a deliberate architectural decision aimed at increasing decentralization and system resilience. The main reasons were:

• Minimizing single points of failure (SPOF): Using “trusted” addresses creates a single attack vector. If the private key of such an address is compromised, an attacker gains full control over bridge operations. History shows that many bridge hacks occurred precisely through the takeover of privileged addresses.
• Ensuring liveness: In the event of loss of access to a “whitelisted” address (e.g. due to lost keys or hardware failure), the bridge would be fully paralyzed with no possibility of rapid recovery. The absence of msg.sender checks allows the system to remain operational regardless of the state of specific wallets.
• Security through logic rather than addresses: Instead of checking who calls a function, the contract focuses on validating the content of the transaction itself (e.g. the correctness of cryptographic signatures or state proofs). This makes the system more autonomous and less dependent on the human factor.

8. Why did the ExpressExecute module have the ability to move real user funds?

The ExpressExecute function was not properly restricted from performing operations with real funds. This was due to a peculiarity of its implementation in the Axelar SDK where by default it was allowed to operate with funds without additional checks.

9. Why was the consensus mechanism that the team previously described as a key security element effectively disabled or bypassed in this case?

This occurred due to a combination of optimization measures and a technical error in the validation logic.

In order to improve economic efficiency (reducing gas costs for users) a “1 of 2” confirmation scheme was chosen. In this model, Axelar acted as a trusted fallback bridge. We operated under the assumption that Axelar is a reliable environment that always validates data before transmission.

10. Was what happened the result of an architectural decision or a specific implementation bug?

The system was originally designed as a structure relying on trusted external protocols (such as Axelar) to ensure security.

The issue arose at the level of the Axelar module logic. The contract mistakenly allowed command execution without passing through all the required validation filters that the architecture intended.

11. Could the attack have been prevented with correct permission and verification settings?

With different settings, the attack might not have occurred. But this would not have solved the core problem, which was the vulnerability of the Axelar integration model.

The issue was that the current implementation of the Axelar module was unsafe by nature. The consensus was designed to function even if one bridge was compromised. However, in this configuration, the Axelar module could not actually guarantee protection if a failure occurred in another bridge.

Even with “ideal settings,” such an architecture would remain vulnerable.

12. Why was the bridge code not updated after an audit with a critical bug dated December 16th? Why was the latest version of the bridge deployed on December 12th despite identified critical vulnerabilities?

The publication of the report does not mean the end of the audit. Changes in the repository do not necessarily mean that the deployed contract code was changed. The report was published after deployment and after MixBytes verified the deployment’s full compliance with the report.

The critical issues listed in the report were marked as fixed and were verified both in the code and in the deployment. Not only critical issues were resolved, but at the moment of deployment there were no open remarks of any level.

Legal and external actions

13. Has the team contacted law enforcement authorities?

The team is working with legal advisors and relevant external specialists, and is taking all the necessary steps within the framework of applicable law. This includes considering and using the applicable mechanisms for cooperation with the relevant authorities.

In the interest of the investigation and for legal reasons, we cannot publicly disclose the details of these interactions. However, we can confirm that this matter is actively being worked on.

14. Will users be informed about the progress of the investigation and its results?

Yes. We plan to regularly inform the community about the progress of the investigation and key findings as confirmed information becomes available. At the same time, we will maintain a balance between transparency and legal constraints so as not to impede the investigation or subsequent actions.

All significant updates and decisions will be published through our official communication channels.

15. How does the team plan to restore the trust of users and partner projects?

Restoring trust is a priority for us. We are building it through transparency, responsibility, and concrete actions:

• Publishing a detailed FAQ and regular investigation updates;
• Presenting a public support plan for affected users within a day of the publication of this FAQ;
• Implementing technical and procedural improvements to prevent similar incidents in the future;
• Actively engaging with partners, infrastructure providers, and auditing teams to enhance the reliability of all services.

We speak openly about identified vulnerabilities and demonstrate through real actions that security and long-term trust remain our core values.

16. Will the bridge be relaunched, and under what security conditions?

Yes, a relaunch of the bridge is planned. However, it will take place only after the full completion of all technical work and the implementation of strengthened security requirements. This is not about a simple restoration, but rather a revision of the architecture, elimination of identified vulnerabilities, and additional verification of all critical components.

We are not considering a fast relaunch at the expense of reliability. User security remains our top priority.

That is, we are considering resuming operations only once the implementation of a set of technical and organizational measures has been met (audit, fixes, additional monitoring, and incident response procedures). These measures are intended to reduce risks and improve reliability, but they do not constitute a guarantee of preventing any future incidents. The resumption of operations may be delayed or may not take place at all if required by the results of the review or due to legal or operational reasons.

17. What specific changes to the architecture and processes will be implemented to prevent this from happening again?

We are already working on a number of changes that will significantly enhance security:

• Fixing the identified vulnerability in the module and controlling access at the smart-contract level.
• Expanding the consensus and introducing additional coordination mechanisms between bridges.
• Infrastructure measures, including a potential mode of automatic shutdown to prevent repeated attacks of a similar nature.

We are implementing measures to substantially reduce the likelihood of such incidents recurring and to strengthen the overall robustness of the system. At the same time, the use of blockchain infrastructure and smart-contracts involves risks, and EYWA provides no guarantees as to the absence of vulnerabilities, disruptions, or losses, as also described in the Terms of Service (AS IS/AS AVAILABLE).

18. How does the team plan to protect users in the future and ensure that their funds are not put at risk?

Unfortunately, our painful experience has clearly demonstrated how unsafe it is to rely on a single third party bridge within a consensus. Going forward, we will strengthen user and client protection as follows:

• Expanding the number of participants in the consensus so that an attack on a single bridge cannot lead to a loss of funds. This will also make a secure consensus bridge accessible to a wider range of chains, as not all projects can afford to integrate two leading bridges such as Axelar and LayerZero at the same time. We plan to seek partners for additional integrations available to a broader spectrum of blockchains regardless of their budget.
• Adding variability to security mechanisms: Consensus bridges must not only be fast but also maximally reliable, including verification of source chain proofs with consideration of transaction finality.

These measures will significantly increase system resilience and reduce risks for all users.