aPriori ~ LockedAprMON

Smart Contract Security Assessment

November 21, 2025

SUMMARY​

ABSTRACT​

Dedaub was commissioned to perform a security audit of LockedAprMON, a contract belonging to the aPriori protocol.

BACKGROUND​

LockedAprMON is an ERC4626-compliant tokenized vault in which deposited assets are locked for a period 45 days, preventing withdrawals/redeemals until the lock period has elapsed.

The contract restricts several of the usual features of ERC4626 vaults:

• Direct transfer/transferFrom operations on shares between users are not allowed. However, it’s possible for a user to approve another one as a spender of their shares. This enables withdraw/redeem operations on behalf of a different user if the appropriate approval has been granted and funds become unlocked.
• Deposits and mints can only be made by and to the caller of the contract; this is done to prevent griefing by other users, since deposit and mint operations reset the lock period.

SETTING & CAVEATS​

This audit report mainly covers the contracts of the at-the-time private https://github.com/apriori-network repository of the aPriori Protocol at commit 3fe03138e248d01be38f9cd64fdd6bde31f49bdb.

Audit Start Date: November 21, 2025

Report Submission Date: November 24, 2025

2 auditors worked on the following contracts:

src/

└── LockedAprMON.py

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than the regular use of the protocol. Functional correctness (i.e. issues in "regular use") is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.

PROTOCOL-LEVEL CONSIDERATIONS​

    ...
    uint256 shares = previewDeposit(_initialDeposit);
    _deposit(_initialOwner, _initialOwner, _initialDeposit, shares);
}

function _convertToShares(uint256 assets, Math.Rounding rounding) ... {
    return assets.mulDiv(totalSupply() + 10 ** _decimalsOffset(), totalAssets() + 1, rounding);
}

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.

CRITICAL SEVERITY​

[No critical severity issues]

HIGH SEVERITY​

[No critical severity issues]

MEDIUM SEVERITY​

[No medium severity issues]

LOW SEVERITY​

[No low severity issues]

CENTRALIZATION ISSUES​

It is often desirable for DeFi protocols to assume no trust in a central authority, including the protocol’s owner. Even if the owner is reputable, users are more likely to engage with a protocol that guarantees no catastrophic failure even in the case the owner gets hacked/compromised. We list issues of this kind below. (These issues should be considered in the context of usage/deployment, as they are not uncommon. Several high-profile, high-value protocols have significant centralization threats.)

...
/**
 * @dev UUPS authorize upgrade restricted to owner
 */
function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}
...

OTHER / ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

...
/**
 * @dev Emitted when the lock period is updated.
 */
event LockPeriodUpdated(address user, uint32 unlockTime);
...

...
function deposit(uint256 assets, address receiver)
...
  _lastDeposit[receiver] = SafeCast.toUint32(block.timestamp);
  emit ILockedAprMON.LockPeriodUpdated(receiver, _lastDeposit[receiver]);
...
function mint(uint256 shares, address receiver)
...
  _lastDeposit[receiver] = SafeCast.toUint32(block.timestamp);
  emit ILockedAprMON.LockPeriodUpdated(receiver, _lastDeposit[receiver]);
...

...
* - While funds are locked, users cannot transfer their shares to another address. This prevents circumvention of the lock mechanism via transfers.
...

function _update(address from, address to, uint256 amount) internal virtual override {
    // only allow minting and burning for deposit and withdraw purposes
    if (from != address(0) && to != address(0))
        revert ILockedAprMON.TransferNotAllowed();
    }
    super._update(from, to, amount);
}

DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.

ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.