ReceiveAfterBuybackSkeletonNID Manual Review Findings

RAS-01M: Inexistent Integration of NID System

Type	Severity	Location
Logical Fault		ReceiveAfterBuybackSkeletonNID.sol:L44

Description:

The ReceiveAfterBuybackSkeletonNID inherits from the TxAuthDataVerifierFacet yet does not apply the TxAuthDataVerifierFacet::requireTxDataAuth modifier to the ReceiveAfterBuybackSkeletonNID::receiveFundsAfterBuyback function.

Impact:

The ReceiveAfterBuybackSkeletonNID::receiveFundsAfterBuyback function does not actually integrate the NID transaction data authorization system.

Example:

Copy
38/**
39 * @notice ReceiveFundsAfterBuyback
40 * @dev Called by funds receiver to receive funds gathered on purchase phase.
41 * @param campaignId The state campaignId.
42 * @param amountOfFractions The amount of fractions to redeem
43 */
44function receiveFundsAfterBuyback(uint256 campaignId, uint256 amountOfFractions) external onlyExternalDelegateCall {
45    address account = ERC2771RecipientStorage.layout()._msgSender();
46    IReceiveAfterBuybackStateFacet(address(this)).checkReceiveAfterBuybackState(campaignId);
47    IDoReceiveAfterBuybackFacet(address(this)).doReceiveAfterBuyback(campaignId, account, amountOfFractions);
48
49    emit FundsAfterBuybackReceived(campaignId, account, amountOfFractions);
50}

Recommendation:

We advise it to be properly applied, ensuring that the NID system's data authorization mechanism is properly integrated.

Alleviation (71cda4ccfdcfa25fb96a4565f1f8143b350dd246):

The proper TxAuthDataVerifierFacet::requireTxDataAuth modifier is imposed by the function in the latest implementation, addressing this exhibit.