Quex V1 Contracts - Quex

1. Introduction

Quex engaged Halborn to conduct a security assessment of their smart contracts from April 21st, 2025, to May 2nd, 2025. The assessment scope was limited to the smart contracts provided to the Halborn team. Commit hashes and additional details are available in the Scope section of this report.

2. Assessment Summary

The Halborn team dedicated 10 days to this engagement, assigning one full-time security engineer to evaluate the smart contracts' security.

The assigned security engineer is an expert in blockchain and smart contract security, with advanced skills in penetration testing, smart contract exploitation, and extensive knowledge of multiple blockchain protocols.

The objectives of this assessment were to:

• Verify that the smart contract functions operate as intended.

• Identify potential security vulnerabilities within the smart contracts.

In summary, Halborn identified several improvements to reduce the likelihood and impact of potential risks, which were mostly addressed by the Quex team. The main ones were:

• Enforce certificate chain validation to maintain integrity and prevent bypasses.

• Limit batch sizes to prevent unbounded loops and mitigate denial-of-service risks in PlatformCA revocation.

• Deprecate or isolate outdated hardware to avoid compromise of the oracle network.

• Disable debug modes in production environments to prevent memory extraction.

• Prevent duplicate PCK registrations in TrustDomainFacet.

• Invalidate stale Trust Domain (TD) quotes to mitigate replay attacks.

• Implement alerts and safeguards to catch silent fund lock failures.

• Ensure explicit cancellation mechanisms to avoid permanent fund locks.

• Patch TEE_TCB_SVN counter leaks to enable effective revocation.

• Harden signature verification against malleability risks.

• Restrict contract call flows to prevent arbitrary executions.

• Clear revoked PCKs to eliminate storage bloat.

• Add comprehensive validation to critical functions.

• Protect against data overwrite from hash collisions.

• Validate upgrade events to prevent misleading off-chain monitoring.

• Review admin logic to prevent unintended privilege escalation.