Team and KYC Verification
The team has securely submitted their personal information to SolidProof.io for verification.
In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.
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 not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
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 DSNOKBeneficiary contract is a beneficiary registry that stores allocation shares, locked destination wallets and passphrase hashes, and records an operator attestation when a beneficiary passes verification. The overall design follows common, well-established patterns on Ethereum.
Ownership Privileges
The ownership of the contract has been assigned to a single operator address, currently the deployer wallet rather than the intended multi-sig. The owner retains full privileges including:
- Verifying a beneficiary after the vault has been triggered, by submitting the matching passphrase preimage.
- Acting as the sole attestor for the off-chain identity and wallet confirmation factors.
- Reading every beneficiary record and allocation across all owners.
- Transferring the operator role through a two-step handover that the new operator must accept.
- The operator cannot add, remove or change beneficiaries; only the vault owner can.
- The operator cannot change a beneficiary's locked destination wallet.
- The operator cannot verify a beneficiary before the vault has been triggered.
- The operator cannot move funds; this contract holds no tokens.
Security Features
The contract implements several positive security features:
- Destination wallets are fixed at registration because no function can change them later.
- A seven day edit lock discourages coerced last-minute changes to the plan.
- Beneficiary verification requires the vault to be triggered and the passphrase preimage to match the stored hash.
- The beneficiary count is capped, so registry loops are bounded and cannot be used for gas exhaustion.
Note - This Audit report consists of a security analysis of the DSNOKBeneficiary smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the D-SNOK team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
high Issues | 1 findings
Resolved
#1 high Issue
Total beneficiary allocation is not required to equal 100 percent
The contract only checks that the running total of allocation basis points stays at or below 10000. The architecture and risk documents state that allocations must equal exactly 100 percent, but nothing enforces a lower bound, so an owner can finish configuration at, for example, 80 percent. Any unallocated portion is never disbursed to beneficiaries; it is swept to the custodial contract and after the recovery window to the treasury. This is an independent path, alongside the disbursement math defect, by which intended beneficiaries lose funds to the platform.
medium Issues | 2 findings
Resolved
#1 medium Issue
Edit lock on the first add blocks adding the rest for seven days
Every mutating beneficiary action sets a seven day edit lock and the same functions are guarded by the edit lock check. As a result, after adding the first beneficiary the owner cannot add a second one for seven days, so assembling a plan with several beneficiaries and reaching the intended 100 percent total takes seven days per additional beneficiary. Combined with the missing 100 percent requirement, an owner who runs out of time can leave funds under-allocated.
Resolved
#2 medium Issue
Operator cannot be rotated in the beneficiary registry
The operator address is set only in the constructor and there is no function to change it, unlike the vault which has a two-step transfer. Beneficiary verification is therefore permanently bound to the deployment-time operator. If the operator multisig must be rotated, which is the documented pre-mainnet plan, or if the key is compromised, verification is either frozen or remains under the old key until the contract is redeployed.
low Issues | 2 findings
Resolved
#1 low Issue
walletLocked is never enforced and lockWallet is a no-op
The walletLocked flag is set to true when a beneficiary is added but is never read anywhere in the logic, so it enforces nothing. The public lockWallet function simply re-sets the flag without checking that the beneficiary exists and without any access restriction beyond the caller's own mapping. The advertised wallet lock-in is documentation rather than an enforced rule.
Resolved
#2 low Issue
lockWallet changes state without an event
The lockWallet function writes to storage but emits no event, so any change it makes is invisible to the off-chain monitoring the platform relies on.
optimization Issues | 2 findings
Resolved
#1 optimization Issue
Loop bounds and counter can be optimised
The loops in getTotalAllocationBps and removeBeneficiary read the array length on each iteration and use a checked increment. Caching the length and using an unchecked increment reduces gas. The arrays are capped at ten entries, so the impact is modest.
Resolved
#2 optimization Issue
Revert strings instead of custom errors
The contract uses require statements with string messages throughout. Custom errors are cheaper and are the current best practice on this compiler version.
informational Issues | 1 findings
Pending
#1 informational Issue
On-chain passphrase hash is brute-forceable for weak secrets
The passphrase is stored on-chain as the keccak256 of the salt concatenated with the preimage, and the preimage is revealed in calldata at verification time. The hash is public, so a weak passphrase can be brute-forced offline, and once verification runs the preimage is visible to everyone. The cryptographic preimage resistance is strong, so the real risk is weak user passphrases.