PYUSDX

proposeMint computes activeAt and expiresAt at proposal time and emits those values in the MintProposed event, but the protocol stores only createdAt in MintProposal. The proposal itself does not retain the timing parameters that were in effect when it was created. Instead, both cancelMint and mint recompute the proposal’s validity window at execution time using the current global values of mintDelay and mintTTL:

// cancelMint — reads current $.mintDelay
activeAt = proposal.createdAt + $.mintDelay;
// mint — reads current $.mintDelay and $.mintTTL
activeAt  = proposal.createdAt + $.mintDelay;
expiresAt = activeAt           + $.mintTTL;

Because setMintDelay and setMintTTL take effect immediately and are not snapshotted per proposal, any admin update retroactively changes the execution window for all pending proposals. This creates a mismatch between what was announced in MintProposed and what is ultimately enforced on-chain. A proposal that appeared scheduled to become valid at one time, or expire at one time, can later become executable earlier, later, or expire sooner or later than originally signaled. In other words, proposal timing is not immutable once proposed; it remains subject to governance or admin intervention until execution or cancellation.

Snapshot activeAt and expiresAt into the MintProposal struct at creation time and use the stored values in cancelMint and mint:

M0 Team: The issue was resolved in PR#52.

The rate limit bucket is keyed by issuer address (mapping(address issuer => Bucket)), not by sender. Portal is the sole ISSUER_ROLE holder for bridge-triggered mints, meaning all cross-chain recipients on a given chain share a single bucket. An attacker can drain the entire bucket in a single transaction:

• Bridge capacity PYUSDX from chain A → B — Portal-B’s bucket is fully consumed
• All subsequent receiveMessage calls on chain B revert with RateLimitExceeded until the bucket refills
• Bridge capacity PYUSDX back from B → A — Portal-A’s bucket is consumed
• Repeat indefinitely

Cost to attacker: Only LayerZero (LZ) gas fees (~$5–50 per round trip, depending on the chain). The PYUSDX capacity is recovered on the destination chain with each hop—resulting in zero net capital loss. Impact: Legitimate cross-chain transfers are blocked for the duration of the bucket refill window (capacity / refillPerSecond seconds). Sustaining the attack requires only enough ETH to cover LZ fees.

Consider a tiered bridge fee model on sendToken: Below threshold X: zero protocol fee. Gas and LZ relayer costs already represent a meaningful fraction of small transfer values, making low-value bucket drain attempts self-deterring. At or above X: charge Y basis points on the full bridged amount. At this scale, fixed gas/LZ costs are negligible relative to capital deployed, and the fee is the only economic deterrent.

M0 Team: Acknowledged.

_calculateRemainingAmount uses Math.tryMul and Math.tryAdd to guard against overflow, returning capacity as a fallback if either operation overflows:

(bool mulOk, uint256 refillAmount) = Math.tryMul(elapsed, refillPerSecond);
(bool addOk, uint256 total)        = Math.tryAdd(remaining, refillAmount);
return (!mulOk || !addOk) ? capacity : uint128(Math.min(total, capacity));

However, both overflow checks are statically unreachable given the input types:

• elapsed is computed as uint40 - uint40, then zero-extended to uint256, so its value is bounded by (2^{40}).
• refillPerSecond is uint128, bounded by (2^{128}).
• Product: (2^{40} \times 2^{128} = 2^{168} \ll 2^{256}) → tryMul will never return false.
• remaining is uint128, bounded by (2^{128}).
• Sum: (2^{128} + 2^{168} < 2^{256}) → tryAdd will never return false.

As a result, the branch (!mulOk || !addOk) ? capacity is dead code. The function will always execute:

uint128(Math.min(total, capacity))

Impact: There is no security risk. However, there are two minor consequences:

• Gas: Math.tryMul and Math.tryAdd each perform checked arithmetic internally, which is more expensive than direct

operations. Since _enforceRateLimit is called on every mint, this overhead accumulates across all issuers over time.

• Readability: A reader encountering tryMul/tryAdd may reasonably assume that overflow is a real concern. This could lead to

unnecessary audit effort or, worse, reliance on the fallback path in future changes where type bounds may differ.

Consider removing the dead code.

M0 Team: The issue was resolved in PR#56.

_beforeFreeze calls _claimFor(account, true), which adds yield to the account's balance but skips both net yield to claim recipient and fee to earner manager transfers. The skipTransfer flag exists to prevent the freeze from reverting if claimRecipient is frozen. However, the fee transfer goes to earnerManager, a protocol address that is effectively never frozen, and the contract is not necessarily paused during a freeze. The fee could safely be collected, but the skipTransfer=true skips it. The fee is only recoverable via manual forceTransfer from the frozen account before unfreezing, requiring off-chain record-keeping of the fee amount and current earner manager address. If the admin unfreezes without performing this step, the fee is permanently lost.

When not paused, transfer the fee to the earner manager before returning:

if (skipTransfer) {
+   if (!paused() && fee > 0) {
+       address feeRecipient = \$.earnerManager;
...
return (yieldWithFee, fee, yieldNetOfFee);
}

M0 Team: Acknowledged.

Portal::quote() is used for estimating cross-chain transfer fees, but it reverts for Wormhole routes because WormholeBridgeAdapter::quote() unconditionally reverts with OnChainQuoteNotSupported(). Users and integrating contracts have no on-chain mechanism to determine the required msg.value before calling sendToken.

However, an on-chain quoting path does exist. Wormhole's ExecutorQuoter::requestQuote can estimate the executor fee, and ICoreBridge.messageFee() provides the core bridge fee, but neither is integrated into the adapter's quote function. If a user underpays, the Executor silently accepts the request (due to the payable(payeeAddress).transfer(msg.value); line in Executor.sol), but the relay provider never delivers the message, and tokens are already burned/locked on the source chain.

Integrate Wormhole's on-chain quote resolution (https://wormhole.com/docs/protocol/infrastructure/relayers/executor-framework/#on-chain-quote-resolution) via ExecutorQuoterRouter. This was designed for integrators that cannot pass off-chain signatures, and must rely on Portal.quote(). Store the ExecutorQuoterRouter address and call quoteExecution() to derive fees on-chain, combining the result with ICoreBridge.messageFee() to return the fee estimate.

M0 Team: Acknowledged.

The documentation states "Other adapters (Hyperlane, Wormhole, etc.) can be added without modifying Portal", however that currently is not the case for a standard Wormhole adapter. The PYUSDX Portal's _sendMessage passes four parameters to IBridgeAdapter::sendMessage (destination chain, gas limit, refund address, and payload). There is no mechanism to pass additional arguments. The M0 Portal supports a fifth extraArguments parameter used by the Wormhole adapter to receive the off-chain signedQuote required by the Executor framework. Without this parameter, the PYUSDX Portal cannot integrate with a Wormhole adapter without either modifying the Portal interface (upgrading) or designing a non-standard adapter that obtains the signed quote through an alternative mechanism.

Add an optional bytes calldata extraArguments parameter to the Portal's _sendMessage and the IBridgeAdapter.sendMessage interface, matching the M0 Portal design.

M0 Team: Acknowledged.

Revoking the OPERATOR_ROLE in LayerZeroBridgeAdapter automatically clears the LayerZero endpoint delegate by setting it to address(0). This creates a availability risk: it removes the ability to call privileged recovery functions (skip, clear, nilify) during a nonce-clog scenario, potentially leading to persistent denial of service.

• When an operator is revoked, the contract automatically clears the delegate.
• LayerZero endpoint functions (skip, clear, nilify) can only be called by:
• The OApp itself, or
• Its registered delegate
• The adapter does not expose wrapper functions for these operations.

Example Scenario: Nonce-Clog DoS

Make sure that the delegate is reset to appropriate address via setDelegate after its clearance.

M0 Team: Acknowledged.

MultiMint.totalAssets() is tracked in 6-decimal extension/PYUSDX units, but replaceAsset() removes reserve assets in the asset’s native decimals. For assets with fewer than 6 decimals, replaceAsset() converts the requested PYUSDX amount into assetAmount using truncation, then:

• decreases assetBalance by truncated assetAmount
• decreases totalAssets by the full untruncated amount

This can make totalAssets smaller than the normalized value of actual remaining reserves. Affected logic:

• wrap path adds normalized amount: src/platform/projects/MultiMint.sol:260
• replace path subtracts raw amount: src/platform/projects/MultiMint.sol:279

Example With a 2-decimal asset:

• wrap 10171 asset units
• normalized backing added = 10171 * 10000 = 101,710,000

Then call replaceAsset(..., amount = 10,171):

• 10,171 PYUSDX units converts to 1 asset unit after truncation
• actual normalized reserve removed = 10,000
• but contract subtracts 10,171 from totalAssets

Post-state:

• expected normalized reserves = 101,700,000
• stored totalAssets = 101,699,829

This creates accounting drift and can silently overcharge replacers. Impact

• totalAssets can become inconsistent with actual normalized reserve balances
• users can overpay when replacing into low-decimal assets

Consider only accepting the the normalized amount for PYUSDX, and refund the rest via Swap Facility. In above example, 10000 would be transferred to extension while 171 is refunded back.

M0 Team: Acknowledged.

MultiMint converts between alt-asset amounts and extension-token amounts using only decimal scaling via _convertAmounts, with no price oracle. As a result, a deposit of 1 USDC always mints exactly 1 PYUSDX-worth of extension tokens, and replaceAsset(1 PYUSDX) always returns exactly 1 USDC, regardless of market price.

Behavior when the asset depegs below $1 In a depeg scenario, wrap(USDC, ...) becomes immediately exploitable. A user can deposit an asset worth only $0.87 and still receive 1e6 extension tokens, which remain redeemable through unwrap for $1 worth of PYUSDX. This creates instant arbitrage at the expense of the extension’s existing PYUSDX backing pool. Each such wrap reduces pyusdxBacking per extension token and dilutes existing holders.

At the same time, replaceAsset becomes economically irrational: no rational actor will spend $1 of PYUSDX to receive only $0.87 of USDC. The result is that reserves accumulate the depegged asset, while no one is incentivized to rotate it out. Net effect: the reserve composition deteriorates as it fills with below-peg assets; extension token holders become collectively undercollateralized; and redemptions become a race. Early unwrappers extract full PYUSDX value, while late holders are left with tokens backed only by impaired assets after pyusdxBacking has been exhausted.

Behavior when the asset trades above $1 If the asset appreciates above peg, the incentives reverse. replaceAsset

becomes attractive because a user can pay $1 of PYUSDX and receive $1.05 of USDC. This drains high-quality reserves until either caps block further inflows or the appreciated asset is fully extracted.

Meanwhile, wrap(USDC, ...) becomes unattractive: the user contributes $1.05 of value but still receives only 1e6 extension tokens, redeemable for just $1. Rational users stop wrapping, which reduces the inflow of good collateral. Net effect: above-peg assets are arbitraged out of reserves, leaving behind only at-peg or below-peg assets.

Beware of this trust assumption.

M0 Team: The issue was resolved in PR#62.

IssuerGateway.burn is restricted by onlyRole(OPERATOR_ROLE) and burns tokens exclusively from msg.sender’s balance. As implemented, there is no function that allows a PYUSDX holder to directly burn their own tokens on-chain.

Redemption Flow The only available redemption path is effectively mediated: 1. A holder enters into a bilateral agreement with an authorized issuer entity (holder of ISSUER_ROLE). 2. The holder transfers PYUSDX to the issuer (off-chain or via an agreed transfer mechanism). 3. An operator calls IssuerGateway.burn(amount) to burn the received tokens from their own balance. 4. The issuer settles the corresponding PYUSD/USD value with the holder through off-chain means.

Consider documenting the custodial redemption dependency explicitly in user-facing materials and the protocol spec

M0 Team: Acknowledged.

When _claimFor is called with skipTransfer=true (during _beforeFreeze and paused _setAccountInfo), the YieldClaimed(account, yieldNetOfFee) event is emitted before the early return. Although the account actually receives yieldWithFee, this event is misleading since no fee is collected by the earner manager, and no yield is actually routed to claimRecipient. Off-chain systems indexing YieldClaimed could incorrectly assume the fee was paid and yield was distributed.

Consider emitting a separate event for yield handling when skipTransfer=true or move the YieldClaimed emission to after the routing logic.

M0 Team: Acknowledged.

Expired mint proposals cannot be cancelled (ActiveMintProposal revert) or executed (ExpiredMintProposal revert), leaving the storage permanently occupied. Over time, frequently expiring proposals accumulate dead storage with no cleanup mechanism.

Consider adding a permissionless function for clearing expired proposals:

function clearExpiredProposal(uint48 mintId) external {
IssuerGatewayStorage storage \$ = _getIssuerGatewayStorage();
MintProposal storage proposal = \$.mintProposals[mintId];
...
delete \$.mintProposals[mintId];
}

M0 Team: Acknowledged.

PYUSDX has two mint paths that bypass IssuerGateway’s timelock. | Caller | Function | Gating | | --- | --- | --- | | ISSUER_ROLE holder (Portal) | PYUSDX.mint → _enforceRateLimit(msg.sender) | Rate limit bucket only | | earnerManager | PYUSDX.distributeReward → _enforceRateLimit(msg.sender) | Rate limit bucket only | Both paths converge on _enforceRateLimit, which includes an explicit bypass for unconfigured callers:

if (bucket.lastRefillTime == 0) return;  // unconfigured → unlimited

Consider configuring rate limits for both portal and earner manager

M0 Team: The issue was resolved in PR#51.

M0 model (single global index):

principal_removed = amount / idx
principal_added   = amount / idx
net Δ principal   = 0   (conserved)

PYUSDX model (per-account index):

principal_removed = ceil(amount / idx_A)
principal_added   = floor(amount / idx_B)
net Δ principal   = floor(amount/idx_B) - ceil(amount/idx_A)   (≠ 0)

Transfers between earners with different rates produce asymmetric principal changes due to:

• Different indexes (idx_A ≠ idx_B)
• Opposite rounding directions (ceil vs floor)

Example

• Sender A: idx_A = 2e12 → removes 50 principal
• Recipient B: idx_B = 4e12 → adds 25 principal

→ Net: −25 principal destroyed

Implications

• Path-dependent yield: Moving funds to higher-rate accounts increases total yield over time (extractable via routing strategies)
• No global invariant: totalEarningPrincipal is not meaningful without normalization

Beware of this behavior and document it

M0 Team: Acknowledged.

The protocol uses a token-bucket rate limiter on minting (_mint → _enforceRateLimit), which limits damage from a compromised ISSUER_ROLE. However, this protection applies only to one path. Several other roles have equal or greater impact with no similar safeguards:

• RATE_LIMIT_MANAGER_ROLE – Can remove all limits → enables unlimited minting
• FREEZE_MANAGER_ROLE + FORCED_TRANSFER_MANAGER_ROLE – Can freeze and fully drain any account instantly
• PAUSER_ROLE – Can halt all protocol activity
• earnerManager – Can redirect all future yield to attacker
• DEFAULT_ADMIN_ROLE – Full takeover: remove limits → grant ISSUER_ROLE → mint unlimited (3 tx)

As a result, the rate limiter only helps in a narrow scenario where only the ISSUER_ROLE is compromised.

Do not treat the rate limiter as broad defense-in-depth—it protects only one attack path. Consider placing high-privilege roles behind stricter controls (e.g., timelock or higher-threshold multisig) to make attacks observable and interruptible.

M0 Team: Acknowledged.

MultiMint::_replaceAsset does not verify that the asset was previously registered via setAssetCap. For an unregistered asset, assetDecimals returns 0, causing _fromExtensionToAssetAmount to produce an incorrect value via _convertAmounts(6, 0, amount). The function then reverts at _revertIfInsufficientAssetBacking, since the balance is zero, but the revert reason is misleading because the function lacks an explicit check. Note _revertIfInvalidAsset only checks if asset is a non-zero address and not pyusdx, it does not check if the asset has already been registered.

Add a registration check early in _replaceAsset:

if (assetDecimals(asset) == 0) revert InvalidAsset(asset);

M0 Team: The issue was resolved in PR#58.

_beforeFreeze and _setAccountInfo both call _claimFor before mutating an earner's balance, but burn does not. Currently, this has no impact since ISSUER_ROLE is held by IssuerGateway (which burns from the operator's own non-earning balance) and Portal (which burns from its own non-earning balance). However, the code handles the earning path without claiming first, creating an inconsistency. If ISSUER_ROLE is ever granted to a contract that burns directly from earning accounts, unclaimed yield would be subject to rounding loss.

Consider adding _claimFor(account) before _subtractEarningAmount in burn if the account is an earner, document that burn targets are expected to be non-earning accounts.

M0 Team: The issue was resolved in PR#61.

HyperlaneBridgeAdapter::handle and WormholeBridgeAdapter::executeVAAv1 are both payable (required by their respective interfaces) but neither forwards msg.value to Portal nor has a withdrawal mechanism. Any ETH sent with these calls is permanently stuck in the adapter contract. While relayers typically send 0 ETH for message-only deliveries, there is no protection against any ETH inclusion (i.e., accidental), and no admin sweep function exists to recover stuck funds. For example, we can see that Hyperlane's process function sends msg.value when executing handle:

https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/Mailbox.sol#L241

// Deliver the message to the recipient.
IMessageRecipient(recipient).handle{value: msg.value}(
_message.origin(),
...
);
}

Consider adding an admin-gated sweep function to recover stuck ETH.

M0 Team: Acknowledged.

WormholeBridgeAdapter::consistencyLevel is an immutable set at construction, and currently its value is undefined throughout the repo. Tests use 15, which is a custom finality level and is not the recommended finalized level. Wormhole's EVM convention defines 1 as finalized, 200 as instant, and 201 as safe. Deploying with a value other than 1 (finalized) introduces reorg risk, and tokens could be minted on the destination chain while the source transaction is rolled back during a chain reorg.

Document the intended production consistencyLevel and verify at deployment that it is set to 1 (finalized) for mainnet, or explicitly acknowledge the reorg risk if a lower finality level is chosen (i.e., for speed).

M0 Team: Acknowledged.

Portal::initialize and BridgeAdapter::initialize skip calling __AccessControl_init() before granting roles, while ExtensionFactory, ExtensionBeacon, and IssuerGateway all call it. In current OpenZeppelin versions this is a no-op, so there is no impact. However, the inconsistency means a future OpenZeppelin upgrade that adds logic to __AccessControl_init() would only take effect in some contracts and silently be missed in others.

Add __AccessControl_init() to Portal::initialize and BridgeAdapter::_initialize.

M0 Team: The issue was resolved in PR#63.

The invariant totalAssets == sum(assetBalance * factor) may not hold true for high decimal assets (>6) as well.

Examples

8-decimal asset:

• wrap 1 leaves remainder 77
• wrap 2 leaves remainder 91
• combined dust 168 crosses the /100 boundary once
• result: aggregate-normalized reserves exceed stored accounting by 1

18-decimal asset:

• wrap 1 leaves remainder 493,295,770,473
• wrap 2 leaves remainder 793,244,671,737
• combined dust exceeds 1e12
• result: aggregate-normalized reserves exceed stored accounting by 1

Beware of this consideration.

M0 Team: The issue was resolved in PR#60.