SMART CONTRACT AUDIT REPORTIssued: 14 Jul 2026 · Version 1.0

AI speed. Human accountability.

CredShields · Smart Contract Audit

Smart Contract Audit

NettyWorth

This report presents the findings of a smart contract security audit conducted against NettyWorth Smart Contracts V3. Findings were identified through manual review of the contract source by the CredShields' security team.

Critical

High

Medium

Low

Info

Total Findings

/ Contents

/ 01: The Picture at a Glance

Executive Summary

CredShields conducted a security audit of the NettyWorth Smart Contracts V3, identifying a total of 40 findings across various severity levels. The initial assessment revealed 8 Critical, 10 High, 14 Medium, and 8 Low severity issues, with no informational findings.

The Critical findings highlight severe vulnerabilities that could lead to significant financial loss or complete system compromise. These include a business logic flaw allowing guaranteed profit per pack through promo code stacking, direct theft of user NFTs, and a critical access control issue where anyone could force-sell a borrower's collateral on the marketplace. Other critical issues noted include a bug where users could pay for packs that are never delivered due to VRF callback failure, and a retroactive model switch in the BuybackPool that could drain the pool.

High severity findings also present substantial risks, such as just-in-time lender deposit sandwich attacks on loan repayment, signature replay attacks due to incomplete signer-binding for FMV quotes, and front-running vulnerabilities that allow the theft of private deals or draining of user USDC approvals. These issues required immediate attention to protect user funds and system integrity.

Following the audit, NettyWorth diligently addressed all identified vulnerabilities. A retest confirmed that all 40 findings have been fixed, demonstrating a strong commitment to the security of their smart contract ecosystem.

Audited scope

https://github.com/nettyworth/NettyWorthV3/tree/91c127cf68074f3a0abe3167bb2e7b7b4dc95503

Retested scope

https://github.com/nettyworth/NettyWorthV3/tree/3103a36ea22bacdd2c21491eead56244a1b2c969

Assessment overview

CredShields performed a comprehensive smart contract security audit for NettyWorth's Smart Contracts V3. This engagement involved a detailed manual code review, architectural analysis, and the application of automated tools to identify potential security vulnerabilities, business logic flaws, and deviations from intended behavior. Our analysis focused on critical areas such as access control mechanisms, financial accounting integrity, potential for economic exploits, reentrancy vectors, denial-of-service attack surfaces, and adherence to best practices in smart contract development.

The audit identified a total of 40 findings across various severity levels, all of which NettyWorth successfully remediated. The most severe issues, categorized as Critical (8 findings), pointed to vulnerabilities that could lead to significant financial loss, direct asset theft, or severe protocol instability. For instance, Discount + Buyback-boost promo code stack yields guaranteed profit per pack highlighted an exploit where specific promo code combinations could allow users to generate guaranteed profit. Similarly, Direct theft of user’s NFT exposed a flaw in access control, enabling unauthorized asset transfer. Critical accounting inconsistencies were also found, such as AcquireDefaultedAsset credits totalDeposited without USDC arriving, which could create phantom liquidity, and AssetNFT.batchBurn on Held-state collateral desyncs AssetLendingPool and P2PTradeEscrow accounting, leading to permanent asset loss. Further critical issues included Marketplace's loan settlement branch skips listing-seller authorization, allowing forced sales of collateral, and PackMachine.fulfillRandomness nested IBuybackPool.registerToken revert kills the VRF callback, leading to user payment without service delivery.

Beyond the critical flaws, 10 High severity findings were discovered, many of which involved front-running opportunities and signature replay attacks. Examples include Just-in-time lender deposit sandwich on loan repayment and buyWithSignature SignedListing is a bearer instrument front-running steals private deals, both illustrating how malicious actors could exploit transaction ordering. Signature integrity was also a concern with FMV quote is a bearer instrument signer-binding never finished, which could enable replay attacks with stale quotes. Access control remained a theme, as seen in AssetLendingPool.financeMarketplacePurchase skips listing.buyer enforcement, allowing private listing hijack.

The audit also uncovered 14 Medium severity findings, often related to less immediate but still impactful business logic errors, potential denial-of-service vectors, or unoptimized contract patterns. Notable issues included Stranded pack open VRF callback can fail and consume payment without delivering cards or refund, indicating a risk of user funds being locked, and PackMachine config setters not pause-gated, creating race conditions. Other medium findings highlighted unbounded array growth in borrowerLoans and potential DoS scenarios like financeMarketplacePurchase allows self-financing of pool's defaulted collateral, which could corrupt accounting. Finally, 8 Low severity findings were identified, encompassing minor security concerns, missing input validations, potential admin foot-guns like PackMachine.rescueERC20 can drain any ERC-20 balance, and issues affecting off-chain integrations or user experience. The successful retest of all 40 findings confirms their resolution, significantly enhancing the security posture of the NettyWorth Smart Contracts V3.

Engagement Details

CLIENTNettyWorth

ASSESSMENT TYPESmart contract security audit

AUDITNettyWorth Smart Contracts V3

REPORT DATE14 Jul 2026

START DATE15 Jun 2026

END DATE02 Jul 2026

RETEST DATE14 Jul 2026

TOTAL FINDINGS40

REVIEWERShashank (shashank@credshields.com) · CredShields

/ Finding severity distribution

Critical

High

Medium

Low

Info

/ 02: At a Glance

Vulnerability Summary

Every finding from this assessment, ordered by severity. Follow an ID for the full write-up.

ID	Vulnerability	Severity	Category	Status
C001	Discount + Buyback-boost promo code stack yields guaranteed profit per pack	Critical	Business Logic (SC02-LogicErrors)	Fixed
C002	AcquireDefaultedAsset credits totalDeposited without USDC arriving phantom liquidity	Critical	Inconsistent Accounting (SCWE-010)	Fixed
C003	Direct theft of user’s NFT	Critical	Access Control (SCWE-016)	Fixed
C004	Marketplace's loan settlement branch skips listing-seller authorization anyone can force-sell any borrower's collateral	Critical	Uncaught Exceptions (SCWE-004)	Fixed
C005	Signed auction cannot be revoked cancelNonce does not gate commitBid; leaked auction signature stays valid post cancellation	Critical	Access Control (SCWE-016)	Fixed
C006	PackMachine.fulfillRandomness nested IBuybackPool.registerToken revert kills the VRF callback; user pays for a pack that is never delivered	Critical	Uncaught Exceptions (SCWE-004)	Fixed
C007	AssetNFT.batchBurn on Held-state collateral desyncs AssetLendingPool and P2PTradeEscrow accounting; loss is permanent	Critical	Inconsistent Accounting (SCWE-010)	Fixed
C008	BuybackPool retroactive model switch (AmountSpent → FMV + bearer fmv=1 quote) drains pool	Critical	Business Logic (SC02-LogicErrors)	Fixed
H001	Just-in-time lender deposit sandwich on loan repayment	High	Front-Running (SCWE-037)	Fixed
H002	FMV quote is a bearer instrument signer-binding never finished	High	Signature Replay Attacks (SCWE-055)	Fixed
H003	Bundle loan over-release marketplace sale of one token releases the entire collateral bundle	High	Uncaught Exceptions (SCWE-004)	Fixed
H004	buyWithSignature SignedListing is a bearer instrument front-running steals private deals and griefs intended buyers	High	Front-Running (SCWE-037)	Fixed
H005	Cross-Collection tokenId Collision latent collateral heist activates on multi-collection allowlist	High	Uncaught Exceptions (SCWE-004)	Fixed
H006	BuybackPool._executeBuyback FMV-quote nonce not reset on registerToken; leaked stale quote drains pool after model flip	High	Business Logic (SC02-LogicErrors)	Fixed
H007	AssetNFT.initiateShipment no maxFee slippage; admin setAppraisal front-run drains user's USDC approval	High	Business Logic (SC02-LogicErrors)	Fixed
H008	AssetLendingPool._collectOriginationFee live-read at disbursement; admin setOriginationFee front-run shrinks borrower's disbursement to zero	High	Business Logic (SC02-LogicErrors)	Fixed
H009	AssetLendingPool.financeMarketplacePurchase skips listing.buyer enforcement private listing hijack	High	Access Control (SCWE-016)	Fixed
H010	Seller nonce cancellation asymmetry marketplace.cancelNonce burns only usedNonces, leaving pool.financeNonces redeemable	High	Access Control (SCWE-016)	Fixed
M001	Stranded pack open VRF callback can fail and consume payment without delivering cards or refund	Medium	Uncaught Exceptions (SCWE-004)	Fixed
M002	borrowerLoans array is append-only unbounded growth, no closing-path cleanup	Medium	Inconsistent Accounting (SCWE-010)	Fixed
M003	Mutable lenderShareBps retroactively reprices in-flight loan interest	Medium	Uncaught Exceptions (SCWE-004)	Fixed
M004	PackMachine config setters not pause-gated race window between user payment and VRF callback	Medium	Missing functionality (SCWE-006)	Fixed
M005	Marketplace allowlist setter has no compatibility canary fee-on-transfer token addition will brick settlement	Medium	Missing functionality (SCWE-006)	Fixed
M006	Discount promo code is not scoped to a PackMachine cross-machine misuse + griefing	Medium	Access Control (SCWE-016)	Fixed
M007	Auction can be cancelled after a bidder commits griefing the bidder's gas + denying the NFT	Medium	Business Logic (SC02-LogicErrors)	Fixed
M008	Default forfeits all loan interest lenders and protocol get only principal back	Medium	Business Logic (SC02-LogicErrors)	Fixed
M009	financeMarketplacePurchase allows self-financing of pool's defaulted collateral DoS of default resolution + permanent accounting corruption	Medium	Denial of Service (SCWE-087)	Fixed
M010	PackMachineFactory.beforeTransfer / .afterTransfer low-level .call() silently swallows validator reverts; selector 0x931820d7 does not match canonical CTS	Medium	Uncaught Exceptions (SCWE-004)	Fixed
M011	PackMachine.resetEffectivePrizePoolSize ignores in-flight VRF reservations; post-reset opens oversell inventory, later callbacks emit CardFailed(tokenId=0)	Medium	Inconsistent Accounting (SCWE-010)	Fixed
M012	NettyWorthMarketplace.hashAuction returns domain-separated hash but commitBid uses bare struct hash; documented API always fails	Medium	Business Logic (SC02-LogicErrors)	Fixed
M013	Transfer-validator revert in PackMachine.fulfillRandomness permanently locks user USDC and stucks pool accounting	Medium	Denial of Service (SCWE-087)	Fixed
M014	BuybackPool pause silently strips buyback rights from every card won during the pause window	Medium	Business Logic (SC02-LogicErrors)	Fixed
L001	missing zero-address check + non-pause-gated; pool unset silently disables buyback registration	Low	Lack of Input Validation (SC05-Lack Of Input Validation)	Fixed
L002	PackMachine.rescueERC20 can drain any ERC-20 balance admin foot-gun	Low	Centralization Risk	Fixed
L003	BuybackPool _redeposit silently no-ops if source machine deregistered NFT stuck, payout already made	Low	Missing Event Emission (SCWE-063)	Fixed
L004	oncePerUser discount code burnable by anyone with leaked OpenPack signature	Low	Signature Replay Attacks (SCWE-055)	Fixed
L005	NettyWorthMarketplace._executeSale royalty deducted from seller proceeds but not paid when royaltyReceiver \== address(0); USDC stranded	Low	—	Fixed
L006	AssetLendingPool.setDefaultLifecycleConfig retroactive window change contradicts docstring; admin can flip phase for in-flight defaults	Low	Business Logic (SC02-LogicErrors)	Fixed
L007	BuybackPool.initializeV2 unprotected reinitializer(2); V2 slot front-runnable	Low	Access Control (SCWE-016)	Fixed
L008	BuybackPool._executeBuyback silently switched BuybackExecuted.payout and totalPaidOut from net to gross; off-chain integrators overstate user proceeds	Low	Uncaught Exceptions (SCWE-004)	Fixed

/ 03: Detailed Findings

Fixed

This issue has been fixed by snapshotting originationFeeBps into Loan.originationFeeBpsSnapshot at _originateLoan and having _collectOriginationFee read the per-loan snapshot in both _borrow and financeMarketplacePurchase a mid-flight setOriginationFee call can no longer retroactively enlarge the fee taken from an in-flight borrower.

H009 · Access Control (SCWE-016)

AssetLendingPool.financeMarketplacePurchase skips listing.buyer enforcement private listing hijack

HighFixed

Description

The C003 fix ported the marketplace's SIGNED_LISTING_TYPEHASH into AssetLendingPool verbatim including the H004 buyer field so signatures over private (buyer-bound) listings are cryptographically distinguishable. The pool builds the struct hash with listing.buyer at L285-297, verifies the signature against the marketplace's EIP-712 domain at L276-303, and the same signature therefore verifies at both contracts. But financeMarketplacePurchase never enforces listing.buyer against msg.sender the way NettyWorthMarketplace._validateListing does at L277-278 (if (listing.buyer != address(0) && listing.buyer != recipient) revert Marketplace__NotIntendedBuyer). A seller who signs a private listing intended for Alice via the marketplace-financed flow a flow that structurally requires seller to have granted an ERC-721 approval to the pool for the tokenId (L347 assetNFT.transferFrom(listing.seller, address(this), tokenId)) can have that signature hijacked by any mempool observer. Attacker Bob calls financeMarketplacePurchase(listing, sig, minDeposit, term) with msg.sender \= Bob; signature verifies, the buyer field is ignored, Bob becomes the borrower, the NFT is collateralised for Bob's loan, and seller receives listing.price. Alice is defrauded of the private allocation. Additionally the pool uses a separate financeNonces mapping (L94) from the marketplace's usedNonces (L105), and the pool exposes no cancelNonce equivalent so a seller who becomes aware of a leaked signature has no on-chain way to revoke it at the pool, even after calling marketplace.cancelNonce(N). Same H004-class defect surviving at the pool boundary.

Affected Code

Business impact

Direct value extraction from any seller who uses the intended marketplace-financed flow: attacker captures (market price − listing.price) whenever a private listing is set below market the classic private-discount steal. The intended-buyer field is present but non-authoritative on the pool side, so H004's guarantee (private listings bound to a specific buyer) does not extend to financeMarketplacePurchase. Compounded by the split-nonce namespace: seller cannot revoke a leaked signature at the pool even after cancelling it at the marketplace, so any leaked signature remains a live liability against every seller-approved pool tokenId until expiry. No admin role required, no special access single-tx mempool front-run.

Recommended next step

Add a buyer enforcement check inside financeMarketplacePurchase after the signature is verified, mirroring NettyWorthMarketplace._validateListing:

if (listing.buyer != address(0) && listing.buyer != msg.sender) revert AssetLendingPool__NotIntendedBuyer();

Retest

Fixed

This issue has been fixed by adding the recommended buyer enforcement check inside financeMarketplacePurchase in AssetLendingPool.sol: if (listing.buyer != address(0) && listing.buyer != msg.sender) revert AssetLendingPool__NotIntendedBuyer();

H010 · Access Control (SCWE-016)

Seller nonce cancellation asymmetry marketplace.cancelNonce burns only usedNonces, leaving pool.financeNonces redeemable

HighFixed

Description

The C003 remediation (commit 9422875) added AssetLendingPool.financeMarketplacePurchase which verifies a marketplace-domain-signed SignedListing against the pool's own financeNonces mapping (AssetLendingPool.sol:94, marked at :321-324). NettyWorthMarketplace.cancelNonce (NettyWorthMarketplace.sol:690-696) burns only usedNonces (NettyWorthMarketplace.sol:105). Both contracts verify the identical SIGNED_LISTING_TYPEHASH under the marketplace EIP-712 domain (pool reconstructs the domain separator explicitly at AssetLendingPool.sol:276-284), so the same signature is valid at both entry points a fact independent of the H009 buyer-binding fix in commit 7b954da. When a seller signs an open listing (buyer=0x0), the signature leaks (Discord, relayer, off-chain marketplace UI, etc.), and the seller calls marketplace.cancelNonce(N) believing this revokes the signature the pool's financeNonces[seller][N] is unaffected. An attacker can then call financeMarketplacePurchase(listing, sig, deposit, term); the signature verifies at AssetLendingPool.sol:301, the pool pulls the NFT via transferFrom(listing.seller, address(this), tokenId) at :351, and the attacker becomes the borrower on a collateralised loan against the seller's NFT a listing the seller had explicitly repudiated. The pool exposes no cancelFinanceNonce function; the only pool-side sellerinvalidation path is either (a) letting listing.expiry pass or (b) revoking the ERC-721 approval to the pool, both of which are indirect and slow.

Affected Code

Business impact

Sellers cannot invalidate a leaked signature at the pool. Any leaked open-listing signature remains a live liability against every seller-approved pool tokenId until listing.expiry. Seller loses full NFT value; attacker captures (marketValue − listing.price) if listing.price is below market, or the entire NFT collateral if listing.price is low. No admin role required anyone with the leaked signature can execute the attack in a single mempool observation. The same signature pathway that H009 addressed via buyer-binding remains open here via the cancellation-namespace split. Effectively re-opens the C005-class revocation gap at a different contract boundary.

Recommended next step

Preferred: unify the nonce namespace. Have financeMarketplacePurchase delegate consumption to marketplace via a new INettyWorthMarketplace.consumeListingNonce(seller, nonce) call, gated on the pool holding a dedicated LENDING_POOL_ROLE at the marketplace. This makes cancelNonce authoritative across both contracts and eliminates the possibility of state divergence. Fallback: add AssetLendingPool.cancelFinanceNonce(uint256 nonce):

function cancelFinanceNonce(uint256 nonce) external {
    _getStorage().financeNonces[msg.sender][nonce] = true;
    emit FinanceNonceCancelled(msg.sender, nonce);
}

Single-line guard at the top of financeMarketplacePurchase:

if (seller == address(this)) revert AssetLendingPool__InvalidSeller();

Add an admin escape hatch gated by paused state, DEFAULT_ADMIN_ROLE, and a minimum staleness age:

function adminForceRefundPendingOpen(uint256 requestId)
    external
    whenPaused
    onlyProtocolRole(Roles.DEFAULT_ADMIN_ROLE)
{
    PendingOpen memory p = _getStorage().pendingOpens[requestId];
    if (p.buyer == address(0)) revert PackMachine__UnknownRequest();
    if (block.timestamp < p.requestTimestamp + MIN_STUCK_AGE)
        revert PackMachine__RequestNotStuck();
    _getStorage().totalEscrowed -= p.escrowedAmount;
    _getStorage().pendingRequestCount--;
    _restoreTierCounts(p.tierWeightsSnapshot);
    IERC20(_getStorage().paymentToken).safeTransfer(p.buyer, p.escrowedAmount);
    delete _getStorage().pendingOpens[requestId];
    emit PendingOpenRefunded(requestId, p.buyer, p.escrowedAmount);
}

The whenPaused gate forces the operator to pause the machine before recovery (defense-in-depth against racing a slow-but-honest fulfillment). MIN_STUCK_AGE (suggested 24 h) prevents adminForceRefundPendingOpen from being used against a request that could still be fulfilled by Chainlink. Alternatively, wrap the beforeTransfer/afterTransfer calls in try/catch inside fulfillRandomness so a validator revert does not roll back the whole callback but that changes the M010 contract with the Creator Token Standard and needs separate consideration.

Retest

Fixed

This issue has been fixed in commit 48934e6 (audit finding report) by implementing the recommended admin escape hatch.

M014 · Business Logic (SC02-LogicErrors)

BuybackPool pause silently strips buyback rights from every card won during the pause window

MediumFixed

Description

PackMachine.fulfillRandomness wraps the IBuybackPool.registerToken(...) call in try/catch at PackMachine.sol:585-594. On any failure including a whenNotPaused revert from BuybackPool the catch fires, emits BuybackRegistrationFailed(tokenId, requestId), and continues with delivery. The NFT transfer to the winner has already succeeded at :571 by the time the buyback registration is attempted. When BuybackPool is paused (an admin action by PAUSER_ROLE), every registerToken overload at :234, :247, :260 (all gated by whenNotPaused) reverts, is silently swallowed, and the resulting card is delivered to the buyer WITHOUT any TokenBuybackInfo record. The user's buyback allocation share of the pack price was still transferred from PackMachine into BuybackPool as part of the pack sale (see PackMachine.sol:626 for the buyback allocation transfer), so the user has already paid for buyback rights they did not receive. No admin retry path exists in BuybackPool.sol registerToken is only callable by an address in registeredPackMachines (i.e., an active PackMachine clone), and PackMachine only ever calls it once per card, inside the VRF callback. There is no adminRegisterToken(tokenId, tier, sourceMachine, amount) function. The buyback registration miss is permanent.

Affected Code

Business impact

Users lose the buyback allocation share they paid for up to buybackAllocationBps of the pack price is transferred into BuybackPool but the corresponding card has no on-chain claim on that value. Effect scales with pause duration × pack sales rate. Because the failure is silent from the user's perspective (only an on-chain event on the PackMachine, no user-facing revert), affected users cannot even distinguish their card from a properly-registered one on-chain; they discover the loss only when a later buyback call reverts BuybackPool__TokenNotRegistered or equivalent. Pause is a routine admin action (upgrades, incident response), so triggering conditions are commonplace.

Recommended next step

drop whenNotPaused from the three registerToken overloads at BuybackPool.sol:234, :247, :260 registration is a bookkeeping write, not a fund transfer, so pausing it serves no safety purpose. executeBuyback can and should remain paused independently to freeze redemptions during incidents. Alternative: add an admin retry function:

function adminRegisterToken(
    uint256 tokenId,
    uint8 tier,
    address sourceMachine,
    uint128 amountPaidPerCard
) external onlyProtocolRole(Roles.DEFAULT_ADMIN_ROLE) {
    _registerToken(tokenId, tier, sourceMachine, amountPaidPerCard);
}

gated by DEFAULT_ADMIN_ROLE with off-chain rate limiting, allowing the operator to backfill missed registrations after the pause ends. Option (a) is preferred because it eliminates the failure mode entirely rather than adding a manual remediation path.

Retest

Fixed

This issue has been fixed in commit 48934e6 by adopting the preferred remediation.

L001 · Lack of Input Validation (SC05-Lack Of Input Validation)

missing zero-address check + non-pause-gated; pool unset silently disables buyback registration

LowFixed

Description

PackMachine.setBuybackPool(address pool) does not validate pool != address(0) and is not pause-gated. If the pool is unset (or set to zero), _handlePayment skips the buyback transfer and routes the full discountedPrice to financeWallet, while fulfillRandomness sets poolActive \= false and skips registerToken. Net effect: users still pay the buyback share, but the cards they win have no buyback right because they were never registered.

Affected Code

Business impact

Silent UX-breaking misconfiguration: cards minted while pool is unset are never registered and can never be bought back.

Recommended next step

Add pause and zero address validation.

function setBuybackPool(address pool) external onlyProtocolRole(Roles.PACK_OPERATOR_ROLE) {
    if (!paused()) revert PackMachine__NotPaused();
    if (pool == address(0)) revert PackMachine__ZeroAddress();
    ...
}

Retest

Fixed

The issue is fixed.

L002 · Centralization Risk

PackMachine.rescueERC20 can drain any ERC-20 balance admin foot-gun

LowFixed

Description

rescueERC20(token) sweeps balanceOf(this) of ANY ERC-20 to admin, including paymentToken. The in-code comment at the function explicitly tags this as a centralization tradeoff. Admin can drain payment-token balances stranded in the contract by VRF callback failure, promo redemption flows, etc. including funds rightfully owed to the buyback pool or treasury under correct accounting.

Affected Code

https://github.com/nettyworth/NettyWorthV3/blob/e2490ee60c62454780fe9e86fed9d2ecfe35a954/contracts/PackMachine.sol#L661-L666

Business impact

Centralization risk; admin can withdraw any token, including payment-token balances that should logically belong to users or the BuybackPool.

Recommended next step

Lockout the payment token: if (token \== IPackMachineFactory($.factory).paymentToken()) revert PackMachine__CannotRescuePaymentToken();. Or maintain an allowlist of rescuable tokens.

Retest

Fixed

This issue is fixed by floor-guarding the payment token by totalEscrowed inside rescueERC20 (with totalEscrowed tracked/updated on every VRF request and fulfillment) the sweep can no longer touch user funds pending VRF settlement. Mechanism differs from the suggested blanket block but achieves the intended user-funds protection.

L003 · Missing Event Emission (SCWE-063)

BuybackPool _redeposit silently no-ops if source machine deregistered NFT stuck, payout already made

LowFixed

Description

The _redeposit checks isPackMachine(sourceMachine); if the source PackMachine has been deregistered by the factory admin between the user winning the card and selling it back, _redeposit returns early the NFT stays in BuybackPool with no event emitted, while the user's USDC payout has already happened. Admin can rescueNFT to recover, but only if they notice. The asymmetry creates an invisible drift: USDC out, NFT in, no signal.

Affected Code

https://github.com/nettyworth/NettyWorthV3/blob/e2490ee60c62454780fe9e86fed9d2ecfe35a954/contracts/BuybackPool.sol#L721-L746

Business impact

Stuck NFTs accumulate silently; admin needs out-of-band signal to know rescue is needed.

Recommended next step

Emit a TokenStuck(tokenId, sourceMachine) event in the no-op branch so off-chain tooling can flag for admin rescue.

Retest

Fixed

This issue is fixed.

L004 · Signature Replay Attacks (SCWE-055)

oncePerUser discount code burnable by anyone with leaked OpenPack signature

LowFixed

Description

openPack(address user, bytes sig, bytes32 codeId) allows msg.sender != user. The play signature only authorises users to receive cards at a given nonce; it does not bind codeId. Anyone with a valid signature for user X can call openPack(X, sig, X_ONCE_USE_CODE) paying for X's pack, gifting the cards to X, but burning X's oncePerUser redemption flag on the code. If the code was a high-value limited-redemption resource, the user is denied future redemption.

Affected Code

Business impact

Mild griefing victim loses oncePerUser eligibility for the consumed code; attacker pays for the pack.

Recommended next step

Bind codeId into the EIP-712 OpenPack typehash so a signature is tied to a specific code (or bytes32(0) for no-code opens), OR restrict openPack so msg.sender \== user.

Retest

Fixed

This issue has been fixed.

L005

NettyWorthMarketplace._executeSale royalty deducted from seller proceeds but not paid when royaltyReceiver \== address(0); USDC stranded

LowFixed

Description

_executeSale computes sellerProceeds \= gross - collectibleFee - royalty - loanDebt unconditionally, pulls gross from the buyer, and pays out the royalty inside a guard if (royalty > 0 && royaltyReceiver != address(0)). If a collection's royaltyInfo returns (receiver=0, amount>0), the amount is deducted from sellerProceeds but no safeTransfer fires the amount is silently retained in the marketplace balance forever (marketplace has no rescueERC20 only pause, config setters, and UUPS upgrade). Numeric: gross=100, fee=5, royalty=30, receiver=0, loanDebt=0 → treasury 5, seller 65, contract retains 30 permanently. Under the canonical AssetNFT this is unreachable because OZ v5.6.1 _setDefaultRoyalty/_setTokenRoyalty revert on address(0) and _deleteDefaultRoyalty leaves state at (0, 0) so the outer royalty > 0 short-circuits. Reachable only if admin allowlists a non-conforming third-party collection whose ERC-2981 implementation returns (0, non-zero) for burned/uninitialized tokens.

Affected Code

https://github.com/nettyworth/NettyWorthV3/blob/e2490ee60c62454780fe9e86fed9d2ecfe35a954/contracts/NettyWorthMarketplace.sol#L474-L558

Business impact

Per-sale silent loss to the seller equal to the phantom royalty amount, on any allowlisted collection whose ERC-2981 returns a non-zero amount with a zero receiver. No path to recover the retained USDC without a marketplace UUPS upgrade adding a sweep function. Unreachable against the canonical AssetNFT.

Recommended next step

Set royalty \= 0 (or refund the residual to the seller) BEFORE computing sellerProceeds when royaltyReceiver \== address(0). Alternatively try/catch the royaltyInfo and treat zero-receiver returns as zero royalty at extraction time, not payout time.

Retest

Fixed

The issue has been fixed.

L006 · Business Logic (SC02-LogicErrors)

AssetLendingPool.setDefaultLifecycleConfig retroactive window change contradicts docstring; admin can flip phase for in-flight defaults

LowFixed

Description

DefaultRecord stores only {loanId, tokenIds, outstandingValue, defaultedAt, resolved} no per-record window snapshot. acquireDefaultedAsset, purchaseDefaultedAsset, and getDefaultPhase all live-read $.acquisitionWindow and $.auctionWindow at every phase check. Meanwhile the setter's own docstring at AssetLendingPoolConfig.sol L347-351 promises: "Changes apply to defaults initiated after this call; existing defaults retain the windows that were active at the time of initiateDefault." Verbatim opposite of the implementation. Concrete: default R at T with acquisitionWindow \= 24h. At T+25h a public buyer's purchaseDefaultedAsset(loanId) is pending in the mempool. Owner front-runs with setDefaultLifecycleConfig(365d, 7d) now 25h < 365d, buyer's tx reverts NotInPurchasePhase. Admin's acquireDefaultedAsset(loanId, ownedMachine, tier) succeeds. Direction of harm is bidirectional (admin can also shrink windows to close Phase-2 early). No direct fund theft buyer's funds never move, so severity is opportunity-cost only.

Affected Code

Business impact

Public Phase-2 buyers can be denied at admin's discretion via retroactive window extension; admin's Phase-1 acquisition can revert via retroactive shrinkage. Integrators and users who trust the docstring are misinformed about the invariant.

Recommended next step

Snapshot acquisitionWindow and auctionWindow into DefaultRecord at _initiateDefault and read those snapshots in every phase check.

Retest

Fixed

The issue has been fixed.

L007 · Access Control (SCWE-016)

BuybackPool.initializeV2 unprotected reinitializer(2); V2 slot front-runnable

LowFixed

Description

initializeV2 is declared external reinitializer(2) with no role guard. After admin upgrades to the V2 implementation (while _initialized \== 1), any EOA can front-run the admin's post-upgrade initializeV2 call, consuming the version-2 reinitializer slot. The body writes only constants (__EIP712_init("NettyWorthBuyback", "1"), defaultBuybackModel \= AmountSpent, modelEnabled[AmountSpent] \= true, modelEnabled[FMV] \= true), which match admin intent so no direct fund loss but the reinitializer(2) slot is permanently burned. Any legitimate need to re-run V2 init (domain-separator quirk, mistaken argument in a future variant) forces escalation to a V3 impl with reinitializer(3). Attack window is bounded to the interval between the upgrade tx mining and the admin's own init tx mining; using upgradeToAndCall(newImpl, initializeV2.selector) (atomic) fully neutralises the finding, so severity depends on the deployment script.

Affected Code

https://github.com/nettyworth/NettyWorthV3/blob/e2490ee60c62454780fe9e86fed9d2ecfe35a954/contracts/BuybackPool.sol#L247-L256

Business impact

Post-upgrade griefing that consumes the version-2 reinit slot without changing final state. No direct fund loss; forces future admin re-init work to escalate to a fresh version.

Recommended next step

Add onlyProtocolRole(Roles.DEFAULT_ADMIN_ROLE) to initializeV2 OR require deployment via upgradeToAndCall(newImpl, abi.encodeCall(BuybackPool.initializeV2, ())) (atomic upgrade + init).

Retest

Fixed

This issue is fixed.

L008 · Uncaught Exceptions (SCWE-004)

BuybackPool._executeBuyback silently switched BuybackExecuted.payout and totalPaidOut from net to gross; off-chain integrators overstate user proceeds

LowFixed

Description

The new buyback-fee mechanism introduced in commit 91c127c splits every buyback payout into sellerAmount \= payout − fee (routed to the caller) and fee (routed to financeWallet), but leaves the pre-existing BuybackExecuted event signature and the internal totalPaidOut accumulator unchanged. _executeBuyback now writes $.totalPaidOut += payout (gross, including fee) and emits BuybackExecuted(tokenId, caller, payout, basis) with the gross payout, while the seller only ever receives payout − fee. Before this commit both surfaces were 1-to-1 with the seller's USDC delta; post-commit they overstate seller proceeds by exactly fee \= (payout × buybackFeeBps) / BPS whenever buybackFeeBps > 0. The companion BuybackFeeCharged(tokenId, feeWallet, fee) event is emitted separately, but any subgraph / analytics / frontend that keys off BuybackExecuted.payout to render a user's realised proceeds has no schema hint that it must now subtract the fee side-event. totalPaidOut is not exposed by a getter and not read anywhere on-chain, so the impact is bounded to off-chain interpretation, but the drift is monotone and silent every buyback with a non-zero fee widens the gap between the reported "paid out" number and the sum of what sellers actually received.

Affected Code

Business impact

Off-chain integrations (subgraphs, indexers, user-facing dashboards, accounting exports) that treat BuybackExecuted.payout as "USDC delivered to the seller" over-report user proceeds by the fee amount, and any external consumer that later exposes totalPaidOut inherits the same drift. No on-chain funds are at risk; the discrepancy is a semantic/observability defect. Downstream harm is limited to misleading UI (users see a "paid X" number that does not match their wallet delta) and misclassified protocol-revenue vs. user-proceeds accounting.

Recommended next step

Extend BuybackExecuted with explicit uint256 sellerAmount and uint256 fee fields (or emit a new event and deprecate the old one) so integrators have unambiguous per-buyback net/gross values. Split $.totalPaidOut into a totalSellerPaid accumulator and a totalFeesCollected accumulator, and expose both via view getters so off-chain systems can key off the correct signal without reconciling two separate events.

Retest

Fixed

This issue has been fixed.

Disclosure

The Reports provided by CredShields are not an endorsement or condemnation of any specific project or issue and do not guarantee the security of any specific project. The contents of this report are not intended to be used to make decisions about buying or selling tokens, products, services, or any other assets and should not be interpreted as such.

Emerging technologies such as Smart Contracts and Solidity carry a high level of technical risk and uncertainty. CredShields does not provide any warranty or representation about the quality of code, the business model or the proprietors of any such business model, or the legal compliance of any business. The report is not intended to be used as investment advice and should not be relied upon as such.

CredShields Audit team is not responsible for any decisions or actions taken by any third party based on the report.

Reviewer(s) & Contact

Shashank

Co-founder, CredShields

Lead Reviewers & Report Signatories

Shashank

Co-founder & CEO · CredShields

Security analyst and penetration tester with 12 years of experience in pentesting and 5 years in managing bug bounty programs. Listed in Google, Facebook, Apple, and 30+ websites' hall of fame for reporting valid security issues.

CVE-2017-7063 CVE-2017-7062 CVE-2017-2458

Aditya Dixit

Audit & Research Lead · CredShields

Senior security researcher and penetration tester with 10+ years in cybersecurity. Led pentest teams at Cobalt and HackerOne; previously at Binary.com. Executed 500+ pentests across banking, fintech, payments, healthcare, telecom, and media, covering web, mobile (iOS/Android), network, cloud, code review, and smart contracts.

OSCP CREST CPSA AWS Security Specialty AWS Cloud Practitioner Qualys VMDR

Smart Contract Audit

Table of Contents

Executive Summary

Audited scope

Retested scope

Assessment overview

Engagement Details

Vulnerability Summary

40 findings across the assessment.

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description

Affected Code

Business impact

Recommended next step

Retest

Description