TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is upgradeable
The contract uses a proxy pattern or similar mechanism, enabling future upgrades. This can introduce risks if the upgrade mechanism is not securely managed.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The ReferralRegister contract implements a small UUPS-upgradeable open registry where any address can claim an unused bytes32 referral code on a first-come-first-served basis and later transfer the recipient slot to a new address. It is the trust anchor for ReferralClaimer, which resolves the recipient by code on every rebate claim. The overall design is short, narrow and easy to reason about; only a few areas need attention:
- register transactions are visible in the mempool and can be front-run by a copy with a higher gas tip, which steals short or valuable codes from the intended user. This affects only direct on-chain registrations from EOAs and does not expose any funds, but it does affect identity capture.
- updateRecipient is a single-step transfer to any non-zero address. A typo permanently loses the code, and the new recipient has no way to refuse a slot that is being handed to them.
- The contract has no Pausable. If a vulnerability is found in the registry or in the off-chain key allocating codes, there is no way to freeze the registry while the issue is being investigated short of redeploying.
Ownership Privileges
The ownership of the contract has been organised through OpenZeppelin's AccessControlEnumerable, with a narrower role set than the other contracts in the suite. DEFAULT_ADMIN_ROLE and UPGRADER_ROLE are granted to the deployer-supplied admin at initialize time. The admin retains the following privileges:
- Upgrading the implementation through the UUPS pattern.
- Granting and revoking roles via AccessControlEnumerable.
- Renouncing roles to harden the deployment after launch.
- Holding the upgrade key, which can change behaviour for every code in one shot if abused.
- The admin cannot register a code on behalf of another address; register is permissionless and msg.sender is hard-bound as the recipient.
- The admin cannot directly change a code's recipient; only the current recipient can call updateRecipient.
- The admin cannot delete a registered code.
- The admin cannot pause the contract; there is no Pausable in the current implementation.
Security Features
The contract implements several positive security features:
- register requires the code to be non-zero and not already registered, and binds the recipient to msg.sender so that off-chain identity is unforgeable on-chain.
- updateRecipient checks msg.sender against the current recipient, ensuring only the legitimate holder can move the slot.
- UpdateReferral events on every state change make the registry fully reconstructible off-chain.
- Implementation contract calls _disableInitializers in the constructor, blocking proxy front-running on initialize.
Note - This audit report consists of a security analysis of the ReferralRegister smart contract. This analysis did not include economic analysis of the contract's tokenomics. Other contracts associated with the project (EvaluationVault, Payout, ReferralClaimer) are covered in separate reports. We recommend investors do their own research before integrating with the contract.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
low Issues | 1 findings
Pending
#1 low Issue
register can be front-run for short or valuable codes
Any externally-visible register transaction can be observed in the mempool, copied with a higher gas tip, and registered by an attacker against an attacker-controlled address. The user then loses access to the code permanently. Affects only direct on-chain registrations from EOAs; no fund loss.
optimization Issues | 3 findings
Pending
#1 optimization Issue
Use custom errors instead of revert strings
Every require uses a string literal.
Pending
#2 optimization Issue
Single-field struct adds no flexibility
ReferralInfo holds only an address recipient. The struct adds no upgrade flexibility because adding fields later changes the struct layout.
Pending
#3 optimization Issue
Constructor non-payable
The implementation constructor is non-payable.
informational Issues | 4 findings
Pending
#1 informational Issue
updateRecipient is single-step
The current recipient can transfer the recipient slot to any non-zero address in a single transaction. There is no acceptance step, so a typo loses the code permanently and the new recipient has no chance to refuse.
Pending
#2 informational Issue
register accepts arbitrary bytes32
There is no on-chain validation of the bytes32 code's format. The off-chain layer is responsible for canonicalisation.
Pending
#3 informational Issue
Contract does not declare IReferralRegister
ReferralRegister implements IReferralRegister implicitly (the getRecipient selector matches), but does not inherit it. Slither flags this as missing-inheritance.
Pending
#4 informational Issue
No Pausable on a critical trust anchor
ReferralClaimer.claim resolves the recipient via referralRegister.getRecipient on every call. If a bug is discovered in ReferralRegister or in the off-chain key that registers codes, there is no way to freeze the registry while the issue is being investigated.