Friendly Casper Token Minter - Casper Association

Prepared by:

HALBORN

Last Updated 08/13/2025

Date of Engagement: July 4th, 2025 - August 8th, 2025

Summary

95% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Missing contract address update functions break protocol when external contracts upgrade
7.2 Incorrect tax calculation in bonding curve leads to reduced output amount, protocol fee loss and reserve imbalances
7.3 Malicious tax configuration enables dex pool drainage and blocks wcspr returns
7.4 Missing getter functions lead to blind trading
7.5 Excessive token approvals in dex liquidity addition
7.6 Missing getter function for token metadata
7.7 Missing upper limit validation for protocol fee configuration
7.8 Missing zero amount validation in trade function
7.9 Lacking event emissions for critical parameter changes
7.10 Missing input validation for graduation parameters
7.11 Mismatch between entrypoint type signatures and their implementations
7.12 Unused contract installation function
7.13 Unnecessary runtime arguments in cep18 initialization
7.14 Unnecessary type conversion in return statement
7.15 Unnecessary wrapper function adds code bloat
7.16 Commented out code and dead code indicates code quality issues
7.17 Documentation inconsistencies
7.18 Inconsistent error handling patterns
7.19 Debug code present in production
7.20 Inconsistent naming conventions for fee and tax parameters

1. Introduction

Casper Association engaged Halborn to conduct a security assessment of the DAO contracts, beginning on July 4th, 2025 and ending on August 8th, 2025. This security assessment was scoped to the smart contracts in the csprfun-core contracts GitHub repository.

The engagement involved a detailed, line-by-line security review of all smart contracts within the Friendly Casper Token Minter ecosystem. This included analysis of the contract code, entry point implementations, bonding curve mechanics, DEX integration, and related administrative controls.

2. Assessment Summary

Halborn's team of blockchain security specialists conducted a rigorous smart contract audit on the Friendly Casper Token Minter ecosystem. The review involved a cross-functional team of experts working over a 4 week period to uncover deeply embedded logic flaws, economic design risks, and practical implementation bugs. The primary goal was to stress-test the security posture for token issuance and trading.

The overall architecture demonstrates robust on-chain controls and correct use of Casper primitives. Most critical business logic passed all functional test cases, supporting safe minting, trading, and graduation to DEX liquidity.

However, the audit identified important areas for improvement, which have been partially addressed:

Insufficient input validation. Some functions accept parameters (like tax or fee rates) that can break economic incentives or degrade product safety.
Unexposed getter/setter functions and excessive token approvals—potentially reducing transparency and exposing contracts to privilege escalation or attack in edge cases.
Lack of event emissions, inconsistent error handling, and documentation gaps—reducing upgrade transparency and maintainability.
Numerous minor code hygiene issues: debug code, commented/dead code, naming mismatches.

3. Test Approach and Methodology

Halborn employs a combined approach of manual code review and automated security testing to ensure a balanced assessment of efficiency, thoroughness, and practicality within the scope of the smart contract review. Manual testing is essential for uncovering logical flaws, process weaknesses, and implementation issues, while automated techniques expand coverage and rapidly identify security best practice violations. The following phases and tools were utilized throughout the assessment:

Research into the architecture, purpose, and usage of the platform.
Manual code review and walkthrough.
Manual assessment of critical Rust variables and functions to evaluate their use and safety, focusing on identifying potential arithmeticrelated vulnerabilities.
Verification of cross-contract call controls.
Review of architecture-related logical controls.
Scanning Rust files for vulnerabilities using cargo audit)
Analysis and review of unit tests and integration tests.
Deployment to testnet via casper-client.

4. RISK METHODOLOGY

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

4.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	METRIC VALUE	NUMERICAL VALUE
Attack Origin (AO)	Arbitrary (AO:A) Specific (AO:S)	1 0.2
Attack Cost (AC)	Low (AC:L) Medium (AC:M) High (AC:H)	1 0.67 0.33
Attack Complexity (AX)	Low (AX:L) Medium (AX:M) High (AX:H)	1 0.67 0.33

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

4.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	METRIC VALUE	NUMERICAL VALUE
Confidentiality (C)	None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C)	0 0.25 0.5 0.75 1
Integrity (I)	None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C)	0 0.25 0.5 0.75 1
Availability (A)	None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C)	0 0.25 0.5 0.75 1
Deposit (D)	None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C)	0 0.25 0.5 0.75 1
Yield (Y)	None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C)	0 0.25 0.5 0.75 1

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N) Partial (R:P) Full (R:F)	1 0.5 0.25
Scope ( $s$ )	Changed (S:C) Unchanged (S:U)	1.25 1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Severity	Score Value Range
Critical	9 - 10
High	7 - 8.9
Medium	4.5 - 6.9
Low	2 - 4.4
Informational	0 - 1.9

5. SCOPE

REPOSITORY

(a) Repository: csprfun-core

(b) Assessed Commit ID: 0dde699

contract/src/cep18/lib.rs
contract/src/main.rs
contract/src/utils.rs

↓ Expand ↓

Out-of-Scope: Third party dependencies and economic attacks.

Remediation Commit ID:

Out-of-Scope: New features/implementations after the remediation commit IDs.

6. Assessment Summary & Findings Overview

Critical

High

Medium

Low

Informational

Security analysis	Risk level	Remediation Date
Missing Contract Address Update Functions Break Protocol When External Contracts Upgrade	High	Solved - 07/16/2025
Incorrect Tax Calculation in Bonding Curve Leads to Reduced Output Amount, Protocol Fee Loss and Reserve Imbalances	High	Solved - 07/16/2025
Malicious Tax Configuration Enables DEX Pool Drainage and Blocks WCSPR Returns	Low	Risk Accepted - 07/16/2025
Missing Getter Functions Lead to Blind Trading	Low	Solved - 07/16/2025
Excessive Token Approvals in DEX Liquidity Addition	Low	Partially Solved - 07/16/2025
Missing Getter Function for Token Metadata	Low	Solved - 07/16/2025
Missing Upper Limit Validation for Protocol Fee Configuration	Low	Not Solved
Missing Zero Amount Validation in Trade Function	Informational	Acknowledged
Lacking Event Emissions for Critical Parameter Changes	Informational	Acknowledged
Missing Input Validation For Graduation Parameters	Informational	Acknowledged
Mismatch Between EntryPoint Type Signatures and Their Implementations	Informational	Solved - 07/17/2025
Unused Contract Installation Function	Informational	Acknowledged
Unnecessary Runtime Arguments in CEP18 Initialization	Informational	Acknowledged
Unnecessary Type Conversion in Return Statement	Informational	Acknowledged
Unnecessary Wrapper Function Adds Code Bloat	Informational	Acknowledged
Commented Out Code and Dead Code Indicates Code Quality Issues	Informational	Acknowledged
Documentation Inconsistencies	Informational	Acknowledged
Inconsistent Error Handling Patterns	Informational	Acknowledged
Debug Code Present in Production	Informational	Solved - 07/16/2025
Inconsistent Naming Conventions For Fee and Tax Parameters	Informational	Acknowledged

Low

Recommendation

Remediation Comment

Recommendation

Remediation Comment

Remediation Hash

https://github.com/FriendlyMarket/csprfun-core/commit/a8f1a70318afeeb324cf190acb85bc783f25604f

7.20 Inconsistent Naming Conventions For Fee and Tax Parameters

Informational

Description

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:N (0.0)

Recommendation

Remediation Comment

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Missing contract address update functions break protocol when external contracts upgrade
7.2 Incorrect tax calculation in bonding curve leads to reduced output amount, protocol fee loss and reserve imbalances
7.3 Malicious tax configuration enables dex pool drainage and blocks wcspr returns
7.4 Missing getter functions lead to blind trading
7.5 Excessive token approvals in dex liquidity addition
7.6 Missing getter function for token metadata
7.7 Missing upper limit validation for protocol fee configuration
7.8 Missing zero amount validation in trade function
7.9 Lacking event emissions for critical parameter changes
7.10 Missing input validation for graduation parameters
7.11 Mismatch between entrypoint type signatures and their implementations
7.12 Unused contract installation function
7.13 Unnecessary runtime arguments in cep18 initialization
7.14 Unnecessary type conversion in return statement
7.15 Unnecessary wrapper function adds code bloat
7.16 Commented out code and dead code indicates code quality issues
7.17 Documentation inconsistencies
7.18 Inconsistent error handling patterns
7.19 Debug code present in production
7.20 Inconsistent naming conventions for fee and tax parameters

// Download the full report

Friendly Casper Token Minter

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed