Is apyUSD Safe? Smart Contract Security Analysis

Security Findings

2 High2 Med1 Low1 Info

High

Centralized Control and Privileged Roles

H-01The `AccessManagedUpgradeable` pattern grants significant power to the designated `Authority` (or `AccessManager`). This entity has the ability to pause the contract, manage the deny-list, set critical external contract addresses (e.g., `unlockToken`, `vesting`, `unlockReceipt`), set the `ccipAdmin`, and authorize upgrades. This high degree of centralization introduces a single point of failure or compromise, where a malicious or compromised `AccessManager` could severely impact the protocol's integrity and user funds.

IssueThe `AccessManagedUpgradeable` pattern grants significant power to the designated `Authority` (or `AccessManager`). This entity has the ability to pause the contract, manage the deny-list, set critical external contract addresses (e.g., `unlockToken`, `vesting`, `unlockReceipt`), set the `ccipAdmin`, and authorize upgrades. This high degree of centralization introduces a single point of failure or compromise, where a malicious or compromised `AccessManager` could severely impact the protocol's integrity and user funds.

FixImplement robust governance mechanisms, such as a multi-signature wallet or a decentralized autonomous organization (DAO), to control the `AccessManager` role. Ensure that critical actions require multiple approvals or community consensus. Clearly document the powers of the `AccessManager` and the procedures for its management.

StatusUnresolved

High

Critical External Contract Dependencies

H-02The `ApyUSD` contract relies heavily on external contracts such as `IUnlockToken`, `IVesting`, `IUnlockReceipt`, and `IAddressList`. Specifically, the `_withdraw` function calls `$.vesting.pullVestedYield()` and `$.unlockReceipt.mint()`, and the `totalAssets()` calculation depends on `$.vesting.vestedAmount()`. Vulnerabilities, malicious behavior, or unexpected state in any of these external contracts could directly lead to security breaches, economic exploits, or operational failures within the `ApyUSD` contract.

IssueThe `ApyUSD` contract relies heavily on external contracts such as `IUnlockToken`, `IVesting`, `IUnlockReceipt`, and `IAddressList`. Specifically, the `_withdraw` function calls `$.vesting.pullVestedYield()` and `$.unlockReceipt.mint()`, and the `totalAssets()` calculation depends on `$.vesting.vestedAmount()`. Vulnerabilities, malicious behavior, or unexpected state in any of these external contracts could directly lead to security breaches, economic exploits, or operational failures within the `ApyUSD` contract.

FixConduct thorough security audits of all dependent external contracts. Implement robust input validation and sanity checks on return values from external calls where possible. Consider implementing circuit breakers or emergency mechanisms to temporarily disable interactions with compromised external contracts. Ensure that the addresses of these external contracts are set by a secure, multi-signature controlled process.

StatusUnresolved

Medium

Strict `receiver` check in `_withdraw`

M-01The `_withdraw` function includes a strict check `if (receiver != owner) revert InvalidCaller();`. This design choice mandates that the `receiver` of the withdrawn assets must be the same as the `owner` (the address initiating the withdrawal). This deviates from the typical ERC-4626 `withdraw` behavior, which usually allows `receiver` to be a different address than `owner`. While this might be an intentional design for specific use cases (e.g., direct receipt minting to the owner), it could limit flexibility for users and lead to unexpected integration issues for systems expecting standard ERC-4626 functionality.

IssueThe `_withdraw` function includes a strict check `if (receiver != owner) revert InvalidCaller();`. This design choice mandates that the `receiver` of the withdrawn assets must be the same as the `owner` (the address initiating the withdrawal). This deviates from the typical ERC-4626 `withdraw` behavior, which usually allows `receiver` to be a different address than `owner`. While this might be an intentional design for specific use cases (e.g., direct receipt minting to the owner), it could limit flexibility for users and lead to unexpected integration issues for systems expecting standard ERC-4626 functionality.

FixClarify and document the rationale behind this strict `receiver` check. If the intention is to allow withdrawals to different addresses, consider removing or modifying this check, ensuring that any such change does not introduce new vulnerabilities. If the current behavior is intentional, ensure it is clearly communicated to integrators and users.

StatusUnresolved

Medium

Custom Storage Slot Management

M-02The contract uses a custom storage slot (`APYUSD_STORAGE_LOC`) for `ApyUSDStorage` via inline assembly. While this pattern is a valid approach for managing custom state in upgradeable contracts, it requires meticulous care. If the chosen slot collides with OpenZeppelin's internal storage slots or any future state variables introduced in subsequent upgrades, it could lead to critical state corruption, loss of funds, or unexpected contract behavior.

IssueThe contract uses a custom storage slot (`APYUSD_STORAGE_LOC`) for `ApyUSDStorage` via inline assembly. While this pattern is a valid approach for managing custom state in upgradeable contracts, it requires meticulous care. If the chosen slot collides with OpenZeppelin's internal storage slots or any future state variables introduced in subsequent upgrades, it could lead to critical state corruption, loss of funds, or unexpected contract behavior.

FixEnsure that the chosen custom storage slot is sufficiently far from known OpenZeppelin storage slots and any other potential future state variables. Maintain a clear and detailed storage layout map for all contract versions. Implement robust testing, including upgrade simulations, to verify storage compatibility before deploying new implementations.

StatusUnresolved

Low

Missing Fee Cap Enforcement in `setUnlockingFee` (Assumed)

L-01The contract defines a `MAX_FEE` constant of `0.01e18` (1%). However, the `setUnlockingFee` function (which is truncated in the provided code but assumed to exist and be `restricted`) is not explicitly shown to enforce this `MAX_FEE` limit. Without this check, a privileged role could potentially set an arbitrarily high unlocking fee, leading to economic exploitation or making withdrawals prohibitively expensive.

IssueThe contract defines a `MAX_FEE` constant of `0.01e18` (1%). However, the `setUnlockingFee` function (which is truncated in the provided code but assumed to exist and be `restricted`) is not explicitly shown to enforce this `MAX_FEE` limit. Without this check, a privileged role could potentially set an arbitrarily high unlocking fee, leading to economic exploitation or making withdrawals prohibitively expensive.

FixEnsure that the `setUnlockingFee` function includes a check to prevent setting the `unlockingFee` above `MAX_FEE`. For example: `require(newFee <= MAX_FEE, "Fee exceeds max");`.

StatusUnresolved

Info

Use of `TransientSlot` for `tokenId`

I-01The contract utilizes `TransientSlot` (`LAST_TOKEN_ID_TSLOT`) to temporarily store the `tokenId` generated during `_withdraw` and retrieve it in `withdrawForReceipt` and `redeemForReceipt`. This pattern is designed to pass values across internal/external calls within a single transaction without permanent storage. While generally safe for its intended purpose, it's a less common pattern that requires careful understanding to ensure correct usage and prevent unexpected behavior if transaction flow is altered or re-entered in an unforeseen way.

IssueThe contract utilizes `TransientSlot` (`LAST_TOKEN_ID_TSLOT`) to temporarily store the `tokenId` generated during `_withdraw` and retrieve it in `withdrawForReceipt` and `redeemForReceipt`. This pattern is designed to pass values across internal/external calls within a single transaction without permanent storage. While generally safe for its intended purpose, it's a less common pattern that requires careful understanding to ensure correct usage and prevent unexpected behavior if transaction flow is altered or re-entered in an unforeseen way.

FixDocument the specific use case and assumptions for `TransientSlot` usage within the contract. Ensure that all developers and integrators understand its ephemeral nature and the implications for transaction design. Verify through testing that the `tokenId` is correctly stored and retrieved under various transaction scenarios.

StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract utilizes robust OpenZeppelin upgradeable components for ERC-20, ERC-4626, pausing, and access control, providing a strong foundation (7.2 Code Security). Reentrancy is mitigated using `ReentrancyGuardTransient` in critical functions like `_withdraw`. However, the `_withdraw` function is complex, involving multiple external calls to `IVesting` and `IUnlockReceipt`, which increases the attack surface and dependency risk (7.6 External). A custom storage pattern using inline assembly for `ApyUSDStorage` introduces a potential for storage collisions if not meticulously managed in future upgrades (7.1 Architecture).

GovernanceHigh1/10

The contract's `AccessManagedUpgradeable` pattern centralizes significant control under an `Authority` (7.3 Access Control). This entity can pause transfers, manage the deny-list, set critical external contract addresses (e.g., `unlockToken`, `vesting`, `unlockReceipt`), and potentially set the `unlockingFee` (7.4 Economic). This high degree of centralization presents a single point of failure or compromise. Furthermore, the `totalAssets()` calculation includes `vestedAmount()` from an external `IVesting` contract, introducing economic risk if the vesting contract's behavior is manipulated or compromised (7.6 External).

UpgradesHigh1/10

The contract employs the UUPS proxy pattern, with `_authorizeUpgrade` restricted to the `AccessManager`, which is a secure approach for upgrade authorization (7.7 Upgrades). However, the use of a custom storage slot (`APYUSD_STORAGE_LOC`) for `ApyUSDStorage` requires careful management during future upgrades to prevent storage collisions with existing or new state variables (7.1 Architecture). Proper upgrade planning and testing are essential to maintain state integrity.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

83.6% in top 10

1.2% in wallets82.4% in contracts

Effective Concentration34.2%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$18.17M across 6 pairs

Curve stblapxUSDanalysed$16.36M Pancakeswap v3apxUSD$1.50M Uniswap v4apxUSD$205.7K Uniswap v4apxUSD$108.9K Uniswap v4apxUSD$879

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x5db4…e99f

Unlocked LP Held By

0x5ed3…dc88

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

10 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 30% (83.6% total → 34.2% effective; 1.2% in EOAs, 82.4% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 90% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 90% of DEX liquidity)
2 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Final Recommendation

AI Copilot

It is recommended to thoroughly review and document the roles and responsibilities of the `AccessManager` to ensure appropriate governance and multi-signature controls are in place for critical operations.…

Read the verdictHide

Conduct comprehensive audits of all external contracts (`IVesting`, `IUnlockReceipt`, `IAddressList`) that `ApyUSD` depends on, as their security directly impacts this contract. Implement explicit checks for `MAX_FEE` in the `setUnlockingFee` function to prevent malicious fee settings. Finally, ensure a robust upgrade strategy is in place, particularly concerning custom storage slots, to prevent state corruption during future contract updates.

Contract

TypeERC1967Proxy

Audit History

1 audit on record

Sep 1583

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Not Signed In

Is apyUSD Safe?

Security Findings

Centralized Control and Privileged Roles

Critical External Contract Dependencies

Strict `receiver` check in `_withdraw`

Custom Storage Slot Management

Missing Fee Cap Enforcement in `setUnlockingFee` (Assumed)

Use of `TransientSlot` for `tokenId`

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of apyUSD?