{"id":1170,"date":"2025-10-13T17:18:31","date_gmt":"2025-10-13T15:18:31","guid":{"rendered":"https:\/\/ackee.xyz\/blog\/?p=1170"},"modified":"2025-10-21T16:22:25","modified_gmt":"2025-10-21T14:22:25","slug":"bitdca-staking-contracts-audit-summary","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/bitdca-staking-contracts-audit-summary\/","title":{"rendered":"BitDCA Staking Contracts Audit Summary"},"content":{"rendered":"<p class=\"p1\">BitDCA is a protocol that enables automatic micro-savings for card payments. The staking contracts are a subcomponent of BitDCA, allowing users to stake BDCA tokens and earn rewards.<\/p>\n<p class=\"p1\">The protocol implements a staking system with NFT-based positions and tiered rewards. It allows users to lock their BDCA tokens for predefined periods in exchange for bonuses. There is also an option for additional bonus distribution during the staking period in USDT and BDCA.<\/p>\n<p class=\"p1\">BitDCA engaged Ackee Blockchain Security to perform a security review of BitDCA Staking contracts with a total time donation of 6 engineering days in a period between June 23 and July 3, 2025.<\/p>\n<p>A second, fix review was performed between August 14 and August 15, 2025.<\/p>\n<p>A third, fix review with a time donation of 1 engineering day was then performed to address unresolved issues from the previous revision.<\/p>\n<h2><span style=\"font-weight: 400;\">METHODOLOGY<\/span><\/h2>\n<ol>\n<li><strong>Verification of technical specification<\/strong><br \/>\nThe audit scope is confirmed with the client, and auditors are onboarded to the project. Provided documentation is reviewed and compared to the audited system.<\/li>\n<li><strong>Tool-based analysis<\/strong><br \/>\nA deep check with Solidity static analysis tool <a href=\"https:\/\/getwake.io\" target=\"_blank\" rel=\"noopener\">Wake<\/a> along with with the <a href=\"https:\/\/marketplace.visualstudio.com\/items?itemName=AckeeBlockchain.tools-for-solidity\" target=\"_blank\" rel=\"noopener\">Solidity (Wake)<\/a> extension is performed, flagging potential vulnerabilities for further analysis early in the process.<\/li>\n<li><strong>Manual code review<\/strong><br \/>\nAuditors manually check the code line by line, identifying vulnerabilities and code quality issues. The main focus is on recognizing potential edge cases and project-specific risks.<\/li>\n<li><strong>Local deployment and hacking<\/strong><br \/>\nContracts are deployed in a local <a href=\"https:\/\/getwake.io\" target=\"_blank\" rel=\"noopener\">Wake<\/a> environment, where targeted attempts to exploit vulnerabilities are made. The contracts&#8217; resilience against various attack vectors is evaluated.<\/li>\n<li><strong>Unit and fuzz testing<\/strong><br \/>\nUnit tests are run to verify expected system behavior. Additional unit or fuzz tests may be written using <a href=\"https:\/\/getwake.io\">Wake Framework<\/a> if any coverage gaps are identified. The goal is to verify the system\u2019s stability under real-world conditions and ensure robustness against both expected and unexpected inputs.<\/li>\n<\/ol>\n<p>We began our review using static analysis tools, including <a href=\"https:\/\/getwake.io\" target=\"_blank\" rel=\"noopener\">Wake<\/a>. We then took a deep dive into the logic of the contracts. For testing and fuzzing, we used <a href=\"https:\/\/getwake.io\" target=\"_blank\" rel=\"noopener\">Wake Framework<\/a>. The Staking contract had an integration with an out-of-scope contract (<code class=\"codehl\">Presale.sol<\/code>) which was treated as a black box for the review purposes. During the review, we paid special attention to:<\/p>\n<ul>\n<li>ensuring the arithmetic of the system is correct;<\/li>\n<li>checking the fairness of the reward distribution;<\/li>\n<li>ensuring the staking process matches the expected behavior;<\/li>\n<li>detecting possible reentrancies in the code;<\/li>\n<li>ensuring access controls are not too relaxed or too strict; and<\/li>\n<li>looking for common issues such as data validation.<\/li>\n<\/ul>\n<h2><span style=\"font-weight: 400;\">SCOPE<\/span><\/h2>\n<p>The audit was performed on commit <code class=\"codehl\">c62d3dd<\/code> in a private repository and the scope was the following:<\/p>\n<ul>\n<li><code class=\"codehl\">Staking.sol<\/code>; and<\/li>\n<li><code class=\"codehl\">StakingNFT.sol<\/code><\/li>\n<\/ul>\n<p>Revision 1.1 was performed between August 14 and August 15, 2025 on commit <code class=\"codehl\">522ad96<\/code>, with the scope the fixes of the previous revision.<\/p>\n<p>Revision 2.0 was performed on commit <code class=\"codehl\">c05674c<\/code>, with the scope the unresolved issues from the previous revision.<\/p>\n<h2><span style=\"font-weight: 400;\">FINDINGS<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The classification of a security finding is determined by two ratings: <\/span><b>impact<\/b><span style=\"font-weight: 400;\"> and <\/span><b>likelihood<\/b><span style=\"font-weight: 400;\">. This two-dimensional classification helps clarify the severity of individual issues. Issues which would be rated as <\/span><i><span style=\"font-weight: 400;\">medium<\/span><\/i><span style=\"font-weight: 400;\"> severity, but which would be likely discovered only by the team, are typically decreased by the likelihood factor to the <em>W<\/em><\/span><i><span style=\"font-weight: 400;\">arning<\/span><\/i><span style=\"font-weight: 400;\"> or <em>I<\/em><\/span><i><span style=\"font-weight: 400;\">nformational<\/span><\/i><span style=\"font-weight: 400;\"> severity ratings.<\/span><\/p>\n<p class=\"p1\">Our review resulted in <strong>25\u00a0findings<\/strong>, ranging from Warning to High severity. The most severe finding was <strong>H2<\/strong>, which would have malformed the reward distribution. BitDCA have fixed all findings except for W3, which has been acknowledged as an intended aspect of the protocol&#8217;s business design. Find BitDCA&#8217;s statement on W3 along with full finding details per revision in the audit report PDF linked below.<\/p>\n<h3><span style=\"font-weight: 400;\">Critical severity<\/span><\/h3>\n<p>No critical severity issues were found.<\/p>\n<h3><span style=\"font-weight: 400;\">High severity<\/span><\/h3>\n<p>H1: Inverted logic in NFT transfer hook<\/p>\n<p>H2: The <code class=\"codehl\">distributeRewards<\/code> function is flawed<\/p>\n<p>H3: The project is not compatible with smart accounts<\/p>\n<h3><span style=\"font-weight: 400;\">Medium severity<\/span><\/h3>\n<p>M1: Hardcoded decimal assumptions<\/p>\n<p>M2: Stake amount restriction can be bypassed<\/p>\n<h3><span style=\"font-weight: 400;\">Low severity<\/span><\/h3>\n<p>L1: Unsafe ERC20 operations<\/p>\n<p>L2: Inconsistent access control<\/p>\n<p>L3: Max stake amount can be exceeded<\/p>\n<p>L4: Missing events for critical state changes<\/p>\n<p>L5: Missing pause modifier on reward distribution<\/p>\n<p>L6: Mint function is performing safe mint<\/p>\n<h3><span style=\"font-weight: 400;\">Warning severity<\/span><\/h3>\n<p>W1: Affiliate program integration<\/p>\n<p>W2: Insufficient data validation<\/p>\n<p>W3: Potential lack of funds<\/p>\n<p>W4: Potential reentrancy due to NFT hook<\/p>\n<p>W5: Uninitialized variables and roles<\/p>\n<p>W6: Unknown swap conditions<\/p>\n<p>W7: Potential price manipulation on rewards distribution<\/p>\n<h3><span style=\"font-weight: 400;\">Informational severity<\/span><\/h3>\n<p>I1: Code duplication<\/p>\n<p>I2: Division by zero in reward calculation<\/p>\n<p>I3: Ambiguous error messages<\/p>\n<p>I4: Use of magic numbers<\/p>\n<p>I5: Missing documentation<\/p>\n<p>I6: Typos<\/p>\n<p>I7: Unused variables<\/p>\n<h2><span style=\"font-weight: 400;\">TRUST MODEL<\/span><\/h2>\n<p class=\"p1\">The admin has excessive powers across all contracts, creating a potential single point of failure. The admin can change critical parameters, pause\/unpause at will, modify tier parameters that affect user funds, and withdraw all tokens at any time via the <code class=\"codehl\">rescueToken<\/code> function. The contracts can be also upgraded to different implementations.<\/p>\n<h2><span style=\"font-weight: 400;\">CONCLUSION<\/span><\/h2>\n<p class=\"p1\"><a href=\"https:\/\/ackee.xyz\">Ackee Blockchain Security<\/a> recommended BitDCA to:<\/p>\n<ul>\n<li class=\"p1\">create documentation for the codebase;<\/li>\n<li>use oracles for price calculation during rewards distribution;<\/li>\n<li>define a specification for the distribution function and adjust the logic to match it;<\/li>\n<li>create a comprehensive test suite;<\/li>\n<li>simulate distribution transactions before executing them; and<\/li>\n<li>address all identified issues.<\/li>\n<\/ul>\n<p><b>Ackee Blockchain Security\u2019s full BitDCA Staking Contracts audit report can be found <a href=\"https:\/\/cdn.prod.website-files.com\/6764059eb839b368ca0adcd9\/68d59e296ed0db2f8ec08bf0_Ackee%20Blockchain%20Staking%20Contracts%20Report.pdf\" target=\"_blank\" rel=\"noopener\">here<\/a>.<\/b><b><\/b><\/p>\n<p><span style=\"font-weight: 400;\">We were delighted to audit BitDCA and look forward to working with them again.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>BitDCA is a protocol that enables automatic micro-savings for card payments. The staking contracts are a subcomponent of BitDCA, allowing users to stake BDCA tokens and earn rewards. The protocol implements a staking system with NFT-based positions and tiered rewards. It allows users to lock their BDCA tokens for predefined periods in exchange for bonuses. There is also an option for additional&hellip;<\/p>\n","protected":false},"author":30,"featured_media":1173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,10,103],"tags":[21,157,24],"class_list":["post-1170","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-audits","category-ethereum","category-wake","tag-audit","tag-bitcoin","tag-ethereum"],"aioseo_notices":[],"featured_image_src":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2025\/10\/bitdca-cover-600x400.png","featured_image_src_square":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2025\/10\/bitdca-cover-600x600.png","author_info":{"display_name":"Tom\u00e1\u0161 Kova\u0159\u00edk","author_link":"https:\/\/ackee.xyz\/blog\/author\/tomas-kovarik\/"},"_links":{"self":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/1170","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/users\/30"}],"replies":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/comments?post=1170"}],"version-history":[{"count":0,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/1170\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media\/1173"}],"wp:attachment":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media?parent=1170"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/categories?post=1170"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/tags?post=1170"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}