assisterr Info
AssisterrAI is at the forefront of the vertical AI paradigm, providing a distributed participant ecosystem for MoA SLMs. We provide no-code infrastructure for the development of SLMs catered to domain-specific use cases. Assisterr’s ecosystem is an internal free market based around the peer review, model creation, and data validation of collaborative contributors, producing a self-sustaining decentralized AI (DeAI) economy. This SLM Factory utilizes MoA architectures built by reciprocatively compensated AI development gig workers incentivized by the Assisterr’s native token.
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 can mint
It is 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.
Final Audit Report for ASSISTERR
Note - This Audit report consists of a security analysis of the ASSISTERR smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the ASSISTERR team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Audit Findings and Recommendations
1. Missing Validation of Parameters
The functions init_platform_config.rs, change_platform_config.rs, and create_proposal.rs lack proper validation of input parameters. This omission can lead to unexpected behaviors, potential security vulnerabilities, and misuse of the contract’s functionalities. We recommend implementing comprehensive parameter validation in all relevant functions to ensure inputs meet expected formats and constraints.
2. Hardcoded Program IDs Limiting Flexibility
The smart contract utilizes hardcoded Program IDs. Hardcoded IDs reduce the flexibility of the contract, making future upgrades or integrations more cumbersome and increasing the risk of incompatibilities. We suggest refactoring the contract to allow dynamic configuration of Program IDs, enhancing adaptability and maintainability.
3. Use of InterfaceAccount for Critical Accounts
Accounts such as contributor_main_ata, contributor_mt_ata, model_treasury_main, asrr_token, mt_token, and others are typed as InterfaceAccount. This abstraction diminishes type safety, potentially allowing unintended account types and increasing the risk of incorrect account associations. We recommend evaluating the necessity of using InterfaceAccount for these accounts and, if possible, using more specific account types to enhance type safety and reduce the risk of errors.
4. Disabled Access Control in complete_fundraise Function
The checks() function, designed to enforce access control and timing constraints, is currently disabled. Critical validation logic in the complete_fundraise.rs file is commented out. This allows any user to invoke the complete_fundraise function without restrictions, potentially leading to unauthorized actions and exploitation. We recommend re-enabling and thoroughly testing the access control mechanisms within the checks() function to ensure only authorized entities can execute sensitive operations.
5. Potential Reentrancy Vulnerabilities in Token Functions
There is no implemented reentrancy check for the send_assr_token and/or mint_mt_tokens functions. The absence of reentrancy protections can expose the contract to reentrancy attacks, where malicious actors exploit the contract’s state during execution. We advise implementing reentrancy guards in the send_assr_token and mint_mt_tokens functions to prevent potential reentrancy attacks and ensure the integrity of state changes.
Disclaimer: This audit report is based on the analysis conducted up to the knowledge cutoff date of January 2025. It is intended to provide insights into the current security posture of the ASSISTERR smart contract. However, it does not guarantee absolute security, and ongoing vigilance is advised.
Files and details
Findings and Audit result
critical Issues | 2 findings
Resolved
#1 critical Issue
Disabled Access Control Checks
The checks() function, which is intended to enforce access control and timing constraints, is currently disabled. All critical validation logic is commented out, allowing any user to invoke the complete_fundraise function without restrictions.
Pending
#2 critical Issue
Incorrect Account Initialization Order
The proposal_vault account's seeds include proposal.key(), but the proposal account is being initialized after proposal_vault. This results in proposal.key() being uninitialized or incorrect at the time proposal_vault is derived, leading to potential address mismatches and failure to initialize the proposal_vault correctly.
high Issues | 5 findings
Resolved
#1 high Issue
Use of Floating-Point Arithmetic Leading to Precision Errors
The calculation of main_token_amount uses floating-point arithmetic (f64), which can introduce precision errors. Smart contracts require deterministic and precise calculations, and floating-point operations can lead to inconsistencies across different environments.
Resolved
#2 high Issue
Missing Check for Fundraising Already Completed
There is no validation to check if fund_raised is already set to true. This omission allows the complete_fundraise function to be called multiple times, potentially leading to double minting of tokens and inconsistent state.
Resolved
#3 high Issue
Lack of Access Control on opt_mt_back Function
The opt_mt_back function allows any signer (contributor) to invoke the function without verifying if the contributor is authorized to opt back the specific proposal.
Pending
#4 high Issue
Missing Check for Proposal State Consistency
The checks function verifies that the proposal is finished and that the proposal_vault has a positive amount. However, it does not check if the proposal has already been opted back, potentially allowing multiple withdrawals
Pending
#5 high Issue
Division by Zero in Upvote Percentage Calculation and use of Floating-Point Arithmetic
The calculation of upvote_percent divides self.proposal.upvotes by the sum of self.proposal.upvotes and self.proposal.downvotes. If both upvotes and downvotes are zero, this results in a division by zero, causing the transaction to panic. Also, the calculation of upvote_percent uses f64 for floating-point arithmetic, which can introduce precision issues. Blockchain environments typically avoid floating-point operations due to determinism and precision concerns.
medium Issues | 9 findings
Pending
#1 medium Issue
Inconsistent Seed Calculation Due to State Mutation
The model_config account is initialized using seeds that include platform_config.model_count + 1. However, platform_config.model_count is incremented after the seeds are used to derive the PDA. This inconsistency can lead to seed mismatches, causing the PDA derivation to fail or reference incorrect accounts.
Pending
#2 medium Issue
Missing Validation on lp_percent Leading to Potential Underflow
The sale_percent is calculated as 100 - (lp_percent + 10 + 1). This calculation does not validate whether lp_percent + 11 exceeds 100, which can lead to sale_percent underflowing and resulting in a very large value due to the unsigned integer wraparound.
Pending
#3 medium Issue
Commented-Out associated_token::token_program Field
In the model_treasury account initialization, the associated_token::token_program field is commented out. This omission can lead to failures in associating the token account correctly, as the associated token program is essential for creating and managing associated token accounts.
Resolved
#4 medium Issue
Potential Precision Loss with Floating Point Operations
The scaled_max_supply is calculated using floating-point arithmetic (f64), which can lead to precision loss and unexpected rounding errors when converting back to u64.
Resolved
#5 medium Issue
Lack of Comprehensive Error Handling in Token Operations
While many operations use the ? operator to propagate errors, it's crucial to ensure that all potential failure points are adequately handled to prevent silent failures or inconsistent states.
Pending
#6 medium Issue
Missing Validation for Vote Amount
The functions vote_proposal and send_mt_token do not verify whether the amount is greater than zero. Allowing zero-value votes or transfers can lead to unnecessary transactions and potential misuse.
Pending
#7 medium Issue
Lack of Proposal State Validation
The vote_proposal function does not verify the current state of the proposal. Without ensuring that the proposal is active and eligible for voting, users could vote on proposals that are closed or finalized, leading to inconsistent state management.
Pending
#8 medium Issue
Potential Missing Constraints on Contributor's Associated Token Account
The contributor_ata is assumed to be correctly initialized and associated with the mt_token and contributor. However, there are no explicit checks to ensure that the associated token account exists and has sufficient balance before attempting transfers.
Pending
#9 medium Issue
Proposal Space Calculation Unverified
The space allocated for the proposal account is set as Proposal::INIT_SPACE + 8. If Proposal::INIT_SPACE does not accurately account for all fields, including the 8-byte Anchor discriminator, this could result in insufficient space, causing account initialization to fail or data corruption.
low Issues | 9 findings
Pending
#1 low Issue
Absence of Constraints on Initialization Parameters
The init_platform_config method accepts parameters like initial_setup_deposit, platform_fee_percent_setup, and lp_authority without enforcing constraints on their values, potentially allowing invalid or harmful configurations.
Pending
#2 low Issue
No Event Emission for Configuration Changes
The change_platform_config function modifies the platform configuration without emitting any events. Emitting events is crucial for off-chain monitoring, debugging, and maintaining transparency of state changes.
Pending
#3 low Issue
Use of Option Types Without Enforcing At Least One Update
The change_platform_config function accepts all parameters as Option types, allowing the possibility of invoking the function without making any actual changes (i.e., all parameters are None). This can lead to unnecessary transactions and potential confusion.
Pending
#4 low Issue
TODO Left in Code: Creator's Main Token Allocation
A TODO comment indicates uncertainty about whether the creator should receive main tokens, suggesting incomplete implementation of token allocations.
Pending
#5 low Issue
Missing Event Emissions for Critical Actions
The function does not emit any events upon completing the fundraise or allocating tokens. Events are essential for transparency, auditing, and off-chain monitoring.
Pending
#6 low Issue
Potential Overflow in Vote Counting
The vote_proposal function increments upvotes or downvotes by the amount without checking for potential overflow. If the amount causes the vote counts to exceed u64::MAX, it will result in an unexpected wrap-around, leading to incorrect vote tallies.
Pending
#7 low Issue
Potential Overflow on Proposal Count
The proposal_count in model_config is incremented without checking for overflow. If proposal_count reaches u64::MAX, further increments will wrap around to zero, potentially causing proposal ID conflicts and address collisions.
Pending
#8 low Issue
Inconsistent Handling of Token Amounts
The create_proposal function sets proposal.amount using the amount parameter but calls send_mt_token with PROPOSAL_CREATION_AMOUNT. This inconsistency can lead to discrepancies between the recorded amount in the proposal and the actual tokens transferred.
Pending
#9 low Issue
Potential Incorrect Seed Usage for model_config
The model_config account uses seeds based on model_config.creator.key() and model_config.token_name. If model_config.token_name is not unique or can be manipulated, it might lead to seed collisions or unauthorized access.
optimization Issues | 2 findings
Pending
#1 optimization Issue
Minimal Error Handling in init_platform_config Method
The init_platform_config method sets the inner state without handling potential errors, such as state inconsistencies or conflicts with existing configurations.
Pending
#2 optimization Issue
Use of Box<Account<...>> for Accounts
The accounts model_config and platform_config are wrapped in Box<Account<...>>. While this is not inherently problematic, using Box can increase the program's memory footprint and may not be necessary unless dealing with large account data structures.
informational Issues | 1 findings
Pending
#1 informational Issue
Potential Integer Overflow in platform_config.model_count
The platform_config.model_count is incremented using += 1 without checking for potential overflow. Although model_count is a u64, continuous increments could theoretically lead to an overflow, causing unexpected behavior.