MAKE CSPR.name - Casper Association

1. Introduction

MAKE engaged Halborn to conduct a security assessment of their CSPR.name contracts on the Casper Network, from May 29th, 2025, to June 16th, 2025. The scope of this assessment was limited to the repository identified by a specific commit hash, with additional details provided in the Scope section of this report.

CSPR.name is a Web3 naming service built on the Casper Network. It enables users to replace complex hexadecimal account identifiers with human-readable names (e.g., smith.cspr), functioning similarly to how Web2 DNS translates IP addresses into domain names.

2. Assessment Summary

The team at Halborn assigned a dedicated, full-time security engineer to evaluate the security of the smart contracts. The security engineer possesses advanced expertise in blockchain and smart contract security, with extensive skills in penetration testing, smart-contract hacking, and comprehensive knowledge of multiple blockchain protocols.

The objectives of this assessment are to:

• Verify that the contract functionalities operate as intended

• Identify potential security vulnerabilities within the contracts

Overall, Halborn identified several areas for improvement to reduce risks and their potential impact, which have been addressed by the MAKE team. The primary recommendations include:

• Increment the minted_tokens_count variable within the mint function after each successful token minting.

• Enforce strict subdomain validation by verifying that the extracted token_name matches a DNS-label pattern using a regex.

• Ensure that the resolved address of the primary name matches the caller’s address to guarantee that only the legitimate owner can set reverse resolution for their address.

• Enable overflow checks in release mode to safeguard the expiration logic from potential integer overflows.

3. Test Approach and Methodology

Halborn employed a combination of manual code review and automated security testing to ensure a comprehensive, efficient evaluation of the smart contracts. Manual testing aimed to identify logical, procedural, and implementation flaws, while automated testing enhanced coverage and rapidly detected deviations from security best practices. The assessment employed the following phases and tools:

• Research into the architecture, purpose, and usage of the protocol.

• Manual code review and walkthrough.

• Manual assessment of critical Rust variables and functions to identify potential arithmetic vulnerabilities.

• Evaluation of cross-contract call controls.

• Logical control review based on the overall architecture.

• Scanning Rust files for known vulnerabilities using cargo audit.

• Integration testing within a local testing environment.