Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report
DART's logo

DART's

Audit name:

[SCA] DART's | RWA Investment | Apr2026

Date:

Jun 2, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the DART's team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The DART's implements an RWA investment protocol for Polygon Mainnet, where USDT-denominated products are registered, purchased, represented by ERC-721 investment NFTs, and later processed for periodic yield distribution and principal return. An ERC-7546 Meta Contract architecture is used to route investment proxy calls to modular function contracts, while Chainlink Automation-compatible upkeep logic is used to identify scheduled yield and maturity workflows.

Document

NameSmart Contract Code Review and Security Analysis Report for DART's
Audited ByIvan Bondar, Kerem Solmaz
Approved ByKornel Światłowski
Websitehttps://darts.ne.jp/en/→
Changelog14/05/2026 - Preliminary Report
02/06/2026 - Final Report
PlatformPolygon
LanguageSolidity
TagsRWA; ERC-721; Upgradable; Claims
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Repositoryhttps://github.com/DART-s-dev/rwa-investment-contracts→
Initial Commit2448ddd
Final Commite338958

Audit Summary

23Total Findings
19Resolved
2Accepted
2Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are not detailed.

    • Project overview is not provided.

    • All roles in the system are partially described.

    • Use cases are not described.

  • Technical description is not detailed.

    • Contract interactions are not described.

    • Run instructions are not provided.

    • Technical specification is not provided.

    • The NatSpec documentation is sufficient.

Code quality

  • The development environment is configured.

Test coverage

Coverage cannot be measured because forge coverage fails to compile the project (stack-too-deep).

  • Foundry covers deployment and core flows in src (unit/fuzz) and test/investment (12 end-to-end scenarios).

  • Negative paths are tested with revert checks on access control, eligibility, timing, and limits.

  • Multi-user flows include several investors per product, tier-gated invest/mint, and admin, Safe, and automation roles.

System Overview

The project implements an RWA investment protocol for Polygon Mainnet and Amoy, where USDT-denominated products are registered, purchased, represented by ERC-721 investment NFTs, and later processed for periodic yield distribution and principal return. An ERC-7546 Meta Contract architecture is used to route investment proxy calls to modular function contracts, while Chainlink Automation-compatible upkeep logic is used to identify scheduled yield and maturity workflows.

The investment system is structured around an ERC-7546 proxy-style bundle in which individual function contracts implement product registration, investing, admin NFT minting, pool deposits and withdrawals, yield distribution, maturity processing, tier configuration, admin control, and read-only getters. Shared state is accessed through ERC-7201-style namespaced storage libraries containing product records, admin allowlists, configuration values, and tier eligibility registries.

Products are registered by whitelisted administrators, and each product receives a deterministic InvestmentNFT contract deployed with CREATE2. Investors purchase units with USDT through invest, while administrators can mint NFTs through mintNFT for off-chain investment flows. Product state tracks offering limits, raised amount, product pool balance, schedule dates, expected yield, distribution progress, maturity progress, required membership tier, and insufficient-balance status.

Yield distribution and maturity are batch-oriented and process up to 50 NFT records per call through InvestmentNFT. Yield amounts are calculated from raised amount, expected yield, and elapsed distribution period, while maturity returns each NFT holder's recorded investment amount and burns the NFT. Automation scans all products through the investment interface and, when invoked by the configured Chainlink Forwarder, calls distributeYield or maturity; those investment calls remain subject to the investment admin allowlist because both functions use onlyWhiteLists.

Files in Scope

  • Getter.sol — Read-only accessors and simulation helpers are provided for products, admins, tier registries, distribution dates, total yield, and per-NFT yield.

  • DistributionDateLib.sol — Month-based distribution date calculations, midnight normalization, month-end alignment, and distribution period calculations are centralized.

  • PurchasePermissionLib.sol — Tier eligibility is checked against registered ERC-721 and ERC-1155 SBT contracts before investment or admin NFT minting.

  • Initialize.sol — Initial admin addresses, USDT address, and Safe multisig wallet address are written during one-time initialization.

  • ControlAdmin.sol — Safe multisig-restricted admin list management is implemented through addAdmin and deleteAdmin.

  • InvestmentFacade.sol — The facade exposes the external investment function surface used by the Meta Contract bundle.

  • CalculateYieldLib.sol — Period yield, individual yield share, and batch tolerance calculations are provided for distribution logic and simulations.

  • SetTier.sol — Whitelisted administrators can configure eligible SBT contract addresses and ERC-1155 token IDs per tier.

  • OnlyOwnerBase.sol — The onlyOwner modifier is implemented by requiring the configured Safe multisig wallet as caller.

  • IInvestmentNFT.sol — The ERC-721-compatible investment NFT interface defines minting, burning, NFT information lookup, investment amount lookup, events, and errors.

  • IAutomation.sol — Automation action types and the forwarder authorization error are defined.

  • InvestmentNFT.sol — ERC-721 investment units are minted and burned by the investment proxy, with per-token investment amounts and admin-controlled metadata URI updates.

  • Deposit.sol — Whitelisted administrators can deposit USDT into a product pool after product, amount, balance, allowance, and maturity checks.

  • DistributeYield.sol — Whitelisted administrators can distribute periodic USDT yield to NFT holders in batches when scheduled distribution conditions are met.

  • IInvestmentEvents.sol — Product, investment, admin, distribution, maturity, and tier registry events are defined.

  • IInvestmentErrors.sol — Custom errors are defined for initialization, access control, product validation, funds, distribution, maturity, and tier configuration failures.

  • Withdraw.sol — Whitelisted administrators can withdraw USDT from a product pool to the configured Safe multisig wallet.

  • Invest.sol — Investors can purchase product units with USDT, subject to offering window, capacity, allowance, balance, and tier eligibility checks.

  • OnlyWhiteListsBase.sol — The onlyWhiteLists modifier is implemented by checking the caller against the stored admin list.

  • MintNFT.sol — Whitelisted administrators can mint investment NFTs for investors before operation start, supporting off-chain investment flows.

  • Automation.sol — Chainlink Automation-compatible upkeep logic scans products and performs yield distribution or maturity calls through the investment interface when called by the configured forwarder.

  • Schema.sol — Product, tier registry, admin list, configuration, and product registration argument structs are defined.

  • IInvestmentFunctions.sol — The investment function interface aggregates external state-changing and read-only function signatures.

  • Maturity.sol — Whitelisted administrators can return principal to NFT holders, burn NFTs, and mark products mature in batches after maturity and distribution completion checks.

  • RegisterProduct.sol — Whitelisted administrators can validate product parameters, deploy a deterministic InvestmentNFT, and store product configuration.

  • Storage.sol — ERC-7201-style storage slots and accessors are defined for product, whitelist, configuration, and tier registry state.

  • IInvestment.sol — Investment functions, errors, and events are combined into a single protocol interface.

  • InvestmentDeployer.sol — The Meta Contract bundle is assembled by registering function selectors, deploying the facade, and initializing the investment proxy.

  • DeployAutomation.s.sol — The Chainlink Automation-compatible contract is deployed from environment-provided investment proxy and forwarder addresses.

  • DeployInvestment.s.sol — The investment proxy is deployed from environment configuration, and dictionary ownership is transferred to the configured Safe multisig wallet.

Privileged roles

Dictionary (ERC-7546 / MC framework)

  • Dictionary Owner (SAFE_MULTISIG_WALLET after deployment): Function-level upgrade authority over all proxy-dispatched code.

    • Can call setImplementation to replace any registered function selector's implementation contract, including fund-moving functions such as withdraw, distributeYield, and maturity. Replacement is instant and silent - no timelock, multi-step confirmation, or on-chain delay is enforced by the Dictionary contract.

    • Can call upgradeFacade to replace the ABI surface contract returned by the proxy's implementation view.

    • Can call transferOwnership to transfer Dictionary ownership to another address.

    • Can call renounceOwnership to permanently disable all future function upgrades and facade changes.

ControlAdmin.sol

  • SAFE_MULTISIG_WALLET (inherited from OnlyOwnerBase): Admin membership can be managed.

    • Can call addAdmin to add an address to the admin list.

    • Can call deleteAdmin to remove an address from the admin list.

SetTier.sol

  • Admin (inherited from OnlyWhiteListsBase): Tier-based purchase eligibility configuration can be managed.

    • Can call setAllowedByTierAddress to replace the SBT contract allowlist for a tier and clear removed ERC-1155 token ID bindings.

    • Can call setAllowedByTierId to replace ERC-1155 token IDs for a registered SBT contract under a tier.

InvestmentNFT.sol

  • Investment admin: NFT metadata can be updated through the admin list stored in the investment contract.

    • Can call setURI to update the shared metadata URI returned for all token IDs.

  • Owner: Investment NFTs can be minted and burned.

    • Can call mint to mint an NFT and record its investment amount.

    • Can call burn to burn an NFT and delete its recorded investment amount.

Deposit.sol

  • Admin (inherited from OnlyWhiteListsBase): Product pool funding can be supplied.

    • Can call deposit to transfer USDT into a product pool.

DistributeYield.sol

  • Admin (inherited from OnlyWhiteListsBase): Yield distribution can be executed.

    • Can call distributeYield to distribute product yield to NFT holders in batches.

Withdraw.sol

  • Admin (inherited from OnlyWhiteListsBase): Product pool funds can be withdrawn to the Safe multisig wallet.

    • Can call withdraw to transfer USDT from a product pool to SAFE_MULTISIG_WALLET.

Invest.sol

  • Eligible investor: Product purchases can be made when the required tier permission is satisfied.

    • Can call invest to purchase product units, transfer USDT, increase product accounting, and mint an investment NFT.

MintNFT.sol

  • Admin (inherited from OnlyWhiteListsBase): Off-chain investments can be represented with NFTs.

    • Can call mintNFT to mint an investment NFT for an eligible investor and increase product raised amount.

Automation.sol

  • Configured forwarder: Automated product lifecycle actions can be executed through the automation contract.

    • Can call performUpkeep to trigger distributeYield or maturity on the investment contract for the encoded product and action type.

Maturity.sol

  • Admin (inherited from OnlyWhiteListsBase): Product maturity processing can be executed.

    • Can call maturity to return principal to NFT holders, burn NFTs, and mark product maturity progress.

RegisterProduct.sol

  • Admin (inherited from OnlyWhiteListsBase): Investment products can be created.

    • Can call registerProduct to validate product parameters, deploy the product NFT contract, and store product configuration.

Potential Risks

Out-of-Scope Components and Third-Party Dependencies

Dependence on MC proxy and dictionary logic: The investment bundle is deployed through InvestmentDeployer with MCDevKit, selector-to-implementation mappings are registered through mc.use, and the resulting proxy address is produced by mc.deploy. The deployed system therefore depends on the MC ERC-7546 proxy and dictionary implementation imported from external packages, while DeployInvestmentScript transfers Dictionary ownership to the configured Safe multisig. Incorrect selector routing, dictionary behavior, or upgrade ownership handling in that external framework could affect every function contract exposed through InvestmentFacade.

Dependence on configured external asset and eligibility contracts: Core accounting and settlement are performed against the ERC-20 address stored as USDT_ADDRESS during initialize, and invest, deposit, withdraw, distributeYield, and maturity all transfer that external token. The protocol is hardcoded to a single payment token (USDT on Polygon) and does not support rebasing, fee-on-transfer, or other non-standard ERC-20 token mechanics - all internal accounting credits the nominal transfer amount without balance-delta verification. Investor eligibility is delegated to external ERC-721 or ERC-1155 contracts registered through setAllowedByTierAddress and setAllowedByTierId, which are queried by PurchasePermissionLib through supportsInterface, balanceOf, and token-id balances. Unexpected behavior or misconfiguration of these external token contracts could block investments, distributions, redemptions, or tier-gated access.

Loop Efficiency

Product scanning grows with registered products: Automation calls getAllProducts and scans every product returned from productIdKeys inside checkUpkeep. Each call copies all stored Schema.Product records into memory before a required distribution or maturity action is selected. A growing product registry could make upkeep checks increasingly expensive and could prevent automated processing from being discovered within practical gas limits.

Batch settlement depends on repeated external calls: DistributeYield and Maturity process NFT holders in batches returned by getNFTInfos, which are capped to a 50-token window. Each distribution batch performs USDT transfers to NFT holders, and each maturity batch performs USDT transfers and burns NFTs through InvestmentNFT. Distribution and redemption of a large product therefore require repeated upkeep or admin-triggered calls across sequential token ID batches, and later holders depend on successful completion of earlier batches.

Cross-Product Fund Isolation

All products share a single USDT balance with soft per-product accounting: Investor USDT from invest, admin USDT from deposit, yield payouts via distributeYield, principal returns via maturity, and admin withdrawals via withdraw all operate on the same usdt.balanceOf(address(this)). The productPool field per product is an internal accounting counter with no actual token segregation. If cumulative rounding from yield calculations across many distributions causes the sum of all productPool values to drift from the real contract balance, one product's settlement could fail because another product's funds are masking the deficit. The contract checks both productPool and usdt.balanceOf(address(this)) independently, but no invariant enforcement ensures their aggregate consistency.

Permissions, Authorization, and Access

Operational powers are concentrated in whitelisted admins: The onlyWhiteLists modifier gates registerProduct, mintNFT, deposit, withdraw, distributeYield, maturity, setAllowedByTierAddress, and setAllowedByTierId through the admin array stored in WhiteListsState. These functions cover product creation, off-chain investment NFT issuance, product pool funding, product pool withdrawal, investor eligibility configuration, yield distribution, and maturity redemption. Compromise or misconfiguration of an admin address could affect product terms, eligibility, settlement timing, and protocol-held USDT flows.

Automation execution depends on admin-list configuration: Automation restricts performUpkeep to the configured forwarderAddress, but the subsequent calls to distributeYield and maturity are made from the Automation contract to functions protected by onlyWhiteLists. Automated settlement can therefore execute only if the Automation contract address is also present in the investment admin list. A mismatch between the configured forwarder, automation address, and admin list could prevent scheduled actions from being performed through the automated path.

Treasury movements are executable by whitelisted admins: Withdraw allows any whitelisted admin to reduce a product's productPool and transfer USDT from the investment proxy to SAFE_MULTISIG_WALLET. The same admin role can call deposit to increase product liquidity and distributeYield or maturity to move USDT to NFT holders. Product pool balances and settlement liquidity are therefore dependent on admin-operated fund movements rather than an autonomous reserve model.

Tier access is controlled by admin-managed external token lists: SetTier replaces the full SBT contract list for each tier and sets ERC-1155 token IDs for registered SBT contracts, while PurchasePermissionLib grants purchase permission based on balances in those configured contracts. Product registration stores only a numeric requiredTier, and the meaning of that tier is determined later by the admin-managed registry. Changes to tier contract lists or token IDs can alter who is eligible to call invest or receive admin-minted investment NFTs for existing products.

NFT metadata is mutable by investment admins: InvestmentNFT allows setURI to be called by any address present in getAdminList on the investment contract. The same URI is returned for all token IDs in the product NFT contract. Admin-controlled metadata changes can alter the off-chain representation of investment NFTs after they have been minted and transferred.

No pause mechanism or circuit breaker exists: The protocol does not implement a pause function or emergency stop across any of its function contracts. If a vulnerability is discovered during active product operation, there is no way to freeze investments, distributions, withdrawals, or maturity processing short of upgrading the affected function implementation through the Dictionary (which requires multisig action but executes instantly once approved). All functions remain callable during any incident window between detection and remediation.

No early redemption or refund path exists before maturity: Once an investor calls invest or receives an NFT via mintNFT, there is no on-chain mechanism to exit the position before the product reaches maturity. No burn-and-refund function, no early withdrawal, and no partial redemption are available. The investor's only exit path is transferring the InvestmentNFT to another party through standard ERC-721 transfer. If the underlying RWA underperforms, if the investor requires liquidity, or if the product experiences extended delays due to insufficient pool balances, the investor remains locked with no protocol-level recourse until maturity executes.

Centralization

Single configured Safe controls admin membership and dictionary ownership: OnlyOwnerBase treats SAFE_MULTISIG_WALLET as the owner for addAdmin and deleteAdmin, and DeployInvestmentScript transfers Dictionary ownership to the same configured address. This address controls the admin set used by operational function contracts and the ownership position for selector-to-implementation routing. Loss of control over that address could affect both privileged operations and future function routing management.

Upgradeability

Dictionary upgrades are instant with no timelock or delay: The Dictionary contract's setImplementation function (inherited from DictionaryBase) directly overwrites the functions[selector] mapping for any registered selector in a single transaction. No timelock, governance vote, multi-step confirmation, or on-chain delay is enforced. The Dictionary owner (SAFE_MULTISIG_WALLET after deployment) can replace the implementation behind any of the 22 registered selectors — including withdraw, distributeYield, maturity, and initialize — with immediate effect on all subsequent proxy calls.

Function-level upgrades affect shared namespaced storage: The deployed investment system is assembled from separate function contracts mapped through the MC dictionary, while all implementation contracts read and write shared ERC-7201 storage slots in Storage. Schema.Product, WhiteListsState, ConfigState, and TierRegistryState are relied on across independent functions such as registerProduct, invest, distributeYield, maturity, and withdraw. An incompatible function implementation upgrade could reinterpret or modify shared product, admin, config, or tier state used by other selectors.

Active products can span upgrade periods: Product state includes multi-step fields such as distributedCount, distributedTokenId, distributedYieldPerCount, totalReturnedAmount, maturedTokenId, and isInsufficientBalance. DistributeYield and Maturity use these fields to resume batched processing across multiple calls, while the MC dictionary model permits individual function implementations to be changed after deployment. Upgrades applied while a product is mid-distribution or mid-maturity could affect pending batches and settlement continuity.

Off-Chain Dependency and Liveness

Automated settlement depends on Chainlink Forwarder execution: Automation restricts performUpkeep to the configured forwarderAddress and uses that call path to invoke distributeYield or maturity on the investment contract. Although the underlying functions remain admin-callable through the investment proxy, the automated path depends on Chainlink Automation checks, the configured forwarder address, and the automation contract being authorized as an investment admin. Forwarder downtime, incorrect deployment configuration, or missed upkeep execution could delay scheduled yield distribution and maturity processing.

Insufficient product pools halt automated processing until replenished and retried: DistributeYield and Maturity set isInsufficientBalance and return when productPool cannot cover the remaining yield or principal obligation. Automation explicitly skips products with isInsufficientBalance in checkUpkeep, and deposit does not clear that flag. A product with insufficient pool accounting can therefore stop being selected by automation until an admin deposits enough USDT and successfully retries the relevant distribution or maturity path.

Findings

Code
―
Title
Status
Severity
F-2026-1687Append-Only Product Registry Causes Permanent Denial of Service on Chainlink Automation checkUpkeep
fixed

Medium
F-2026-1687Reverting USDT Transfer in Push-Payment Loop Permanently Blocks Product Distribution and Maturity
fixed

Medium
F-2026-1702Unrestricted NFT Transferability Bypasses Tier-Based Access Control After Purchase
mitigated

Medium
F-2026-1686Empty NFT Batch in distributeYield Causes Permanent Automation Denial-of-Service and Product Lifecycle Deadlock
fixed

Medium
F-2026-1720 Yield Escrow Permanently Locked After NFT Burn on Maturity
fixed

Medium
F-2026-1694Missing Constraint Between Distribution Schedule End and Maturity Date Leads to Unexpected Locking Schedule
fixed

Low
F-2026-1687Restored Product Funding Does Not Clear isInsufficientBalance Flag, Causing Automation to Remain Stalled
fixed

Low
F-2026-1686Inconsistent Integer Size in Admin Array Iteration Leads to Denial of Service
fixed

Low
F-2026-1686Missing Zero-Address Validation in Initialization and Admin Management Leads to Permanent Misconfiguration
fixed

Low
F-2026-1702Flat Admin Whitelist Without Role Separation Grants Full Operational Power to Every Admin Key
mitigated

Low
1-10 of 23 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/DART-s-dev/rwa-investment-contracts→
Initial Commit2448ddd484c4e06ba81e207ba8e1e95781ce9879
Final Commite3389585b172da80219f13f11650ff5d6c6f0940
WhitepaperN/A
Requirementshttps://github.com/DART-s-dev/rwa-investment-contracts/tree/main/docs→
Technical Requirementshttps://github.com/DART-s-dev/rwa-investment-contracts/tree/main/docs→

Assets in Scope

Automation.sol - Automation.sol
CalculateYieldLib.sol - CalculateYieldLib.sol
ControlAdmin.sol - ControlAdmin.sol
DeployAutomation.s.sol - DeployAutomation.s.sol
DeployInvestment.s.sol - DeployInvestment.s.sol
Deposit.sol - Deposit.sol
DistributeYield.sol - DistributeYield.sol
DistributionDateLib.sol - DistributionDateLib.sol
Getter.sol - Getter.sol
IAutomation.sol - IAutomation.sol
IInvestment.sol - IInvestment.sol
IInvestmentErrors.sol - IInvestmentErrors.sol
IInvestmentEvents.sol - IInvestmentEvents.sol
IInvestmentFunctions.sol - IInvestmentFunctions.sol
IInvestmentNFT.sol - IInvestmentNFT.sol
Initialize.sol - Initialize.sol
Invest.sol - Invest.sol
InvestmentDeployer.sol - InvestmentDeployer.sol
InvestmentFacade.sol - InvestmentFacade.sol
InvestmentNFT.sol - InvestmentNFT.sol
Maturity.sol - Maturity.sol
MintNFT.sol - MintNFT.sol

Appendix 3. Additional Valuables

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer