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 DSNOKDisbursement contract holds owners' deposited tokens and distributes them by basis-point allocation to verified beneficiaries once a vault is triggered, taking a platform fee and sweeping any remainder to the custodial contract. 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:
- Recording a trigger and executing disbursements to verified beneficiaries.
- Executing the fallback sweep of unclaimed funds to the custodial contract.
- Setting the fee rate up to a three percent cap and changing the fee receiver and high-value threshold.
- Pausing and unpausing deposits, withdrawals and disbursements.
- The operator can only send disbursements to the beneficiary's pre-registered locked wallet, not to an arbitrary address.
- The operator cannot set the fee above the three percent cap, so the fee can never reach twenty five percent.
- The operator cannot disburse twice for the same beneficiary and token, nor outside the verification window.
- The operator role is transferred through a two-step handover that the new operator must accept.
Security Features
The contract implements several positive security features:
- All token transfers use the safe ERC-20 wrapper and follow a checks-effects-interactions order with reentrancy protection.
- Each beneficiary and token pair can be disbursed only once, preventing double payouts.
- Disbursements are bounded by a verification window and route only to locked beneficiary wallets.
- The fallback sweep can only send funds to the custodial contract, never to an arbitrary address.
Note - This Audit report consists of a security analysis of the DSNOKDisbursement 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
critical Issues | 1 findings
Resolved
#1 critical Issue
Disbursement shares are computed from a shrinking base
executeDisbursement reads the current deposit balance as the base, computes the beneficiary gross as base times allocation basis points divided by 10000, and then subtracts that gross from the deposit. Because the base shrinks after each payout, every beneficiary after the first is paid a percentage of the reduced remainder rather than of the original deposit. With a 1000 token deposit split 60 and 40 percent, the first beneficiary receives 600 but the second receives only 160 instead of 400, and 240 is stranded and later swept to the treasury. The outcome also depends on the operator-chosen order, which enables favoritism. This is a deterministic, high likelihood loss of funds for intended beneficiaries.
medium Issues | 4 findings
Resolved
#1 medium Issue
High-value timelock is advertised but not enforced and the threshold is unused
recordTrigger emits a TimeLockApplied event announcing a release time twenty four hours in the future, but it never sets the time-lock release value. The time-lock check treats an unset value as already passed, so unless the operator separately calls applyTimeLock, disbursement is allowed immediately and the emitted event misleads anyone watching it. Separately, the high value threshold is stored and settable but never compared against anything, so high value detection is entirely manual and off-chain.
Resolved
#2 medium Issue
Deposit accounting trusts the requested amount
The deposit function credits the requested amount to the owner's balance and then pulls that amount with safeTransferFrom. For fee-on-transfer or rebasing tokens the contract receives less than the requested amount, so the owner is credited more than the contract actually holds. Because balances are commingled in one contract, the shortfall surfaces later as failed transfers for the last beneficiary or sweep and can affect other owners. No token allowlist exists.
Acknowledged
#3 medium Issue
Beneficiaries have no permissionless path; operator can censor payouts
Every step that moves an estate to its beneficiaries is gated solely on the operator: only the operator can verify a beneficiary and only the operator can execute a disbursement, and there is no permissionless path for a beneficiary to claim what they are owed. A negligent or malicious operator can simply never verify or disburse, after which the funds drift to the custodial contract and ultimately the treasury. Some operator involvement is inherent to the off-chain verification design, so the real gap is the absence of any time-bounded fallback that lets beneficiaries recover without the operator.
Resolved
#4 medium Issue
Operator cannot be rotated in the disbursement contract
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. All disbursement and sweep functions are therefore permanently bound to the deployment-time operator. If the operator key must be rotated, which is the documented pre-mainnet plan, the contract cannot follow and would need to be redeployed with deposits migrated.
low Issues | 4 findings
Pending
#1 low Issue
Verification window starts at an operator-chosen timestamp
The seven day verification window, and the timing of the fallback sweep and the custodial recovery window that follow, all start from the timestamp at which the operator calls recordTrigger, not from the moment the vault was actually triggered on-chain. Because the operator decides when to record the trigger, they control the start of the whole post-trigger lifecycle and can effectively delay or compress the time beneficiaries have to be verified.
Pending
#2 low Issue
Owners pay a fee to withdraw their own pre-trigger principal
The withdraw function deducts the platform fee rate, currently 1.5 percent and up to 3 percent, from the owner's own deposited funds before any disbursement has occurred. The operator can raise the rate to the cap with no notice or delay, and the new rate applies to funds already deposited. Owners therefore pay a service fee simply to retrieve their own principal.
Resolved
#3 low Issue
Fee receiver change is silent
setFeeReceiver changes the address that receives all platform fees but emits no event, unlike setFeeRate and setHighValueThreshold. A change to where fees flow should be logged.
Pending
#4 low Issue
Deployed source does not match documented verification status
The deployment notes state that all four Sepolia contracts are verified, but the disbursement contract is not source-verified on the explorer at the time of this review; only the bytecode is published. The bytecode footer confirms the 0.8.24 compiler and the embedded peer addresses match the documented vault, beneficiary and custodial addresses, but the missing source reduces transparency for the contract that actually holds user funds.
optimization Issues | 1 findings
Resolved
#1 optimization Issue
Revert strings instead of custom errors
The contract uses require statements with string messages throughout. Custom errors are cheaper to deploy and to revert with on this compiler version.
informational Issues | 1 findings
Pending
#1 informational Issue
Operator chooses disbursement order
Disbursements are executed one beneficiary at a time and the operator decides the order and timing. Once the share-calculation defect is corrected the order no longer changes amounts, but the operator still controls sequencing, which is worth documenting for transparency.