<aside> 💡 NB: Teams were given the opportunity to write a comment in response to their protocol’s assessment. Neither the Foundation nor its Bridge Assessment Committee has made any edits to the text below.

</aside>

At deBridge, our core focus lies in building innovative products and secure infrastructure to advance the cross-chain space and the overall Web3 ecosystem. When we learned that Uniswap, one of the leading protocols in the field, was exploring cross-chain capabilities and new functionalities, we were thrilled because we saw great potential synergies between Uniswap and deBridge. During our communication with the bridge committee throughout the assessment process, we received a draft report indicating that deBridge does not fully meet the requirements for Uniswap DAO's cross-chain governance use case. This prompted us to analyze the specific criteria and metrics that were not satisfied, as well as the quantitative measures used to evaluate the maturity of reviewed projects so that teams can understand what areas they should focus on moving forward to iterate on improvements. To gain a better understanding of our ineligibility in this process and how we differ from eligible projects, we have engaged with the committee. Unfortunately, the answers and indications we have received thus far have been vague and unclear, making it challenging to assess the evaluation process, project criteria, and eligibility requirements. Based on the feedback received from the committee, it seems that the primary reason for our ineligibility is our plan to introduce economic guarantees through delegated staking and slashing. While this is a unique aspect not currently provided by most projects, the committee has commented that our published documentation mainly focuses on the desired future state rather than the current state, stating that "staking and slashing are not currently implemented." Moreover, we were informed that "the system is designed for 12 validators, of which only 11 are denoted as active." when the deBridge infrastructure ("system") can actually support any number of validators. We have sought clarification regarding the desired number of validators or requirements for participants in the validation mechanism, but we are still awaiting a response. Despite providing multiple comments and feedback on various paragraphs, most of them were not accommodated in the report. Similarly, the committee has not provided specific metrics, nor offered clarifications on which requirements have not been fulfilled and where improvements can be made. Understanding these requirements and quantitative criteria are crucial as a project with 100% historical performance and security is deemed ineligible, while others with security incidents and publicly discovered vulnerabilities are endorsed. We are deeply frustrated by this entire process. As advocates for fairness and transparency in this space, we strongly urge the committee to provide clear reasoning and in-depth details. We believe transparency and consistency are essential for building a strong ecosystem, and we hope the committee will address these concerns.