reviewRecipients DonationVotingMerkleDistributionDirectTransferStrategy

[tnkshuuhei]

I'm trying to use DonationVoting strategy, and stuck on how to execute reviewRecipients function.

allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol

Lines 40 to 58 in 14ef520

	/// @notice Struct to hold details of the application status
	/// @dev Application status is stored in a bitmap. Each 4 bits represents the status of a recipient,
	/// defined as 'index' here. The first 4 bits of the 256 bits represent the status of the first recipient,
	/// the second 4 bits represent the status of the second recipient, and so on.
	///
	/// The 'rowIndex' is the index of the row in the bitmap, and the 'statusRow' is the value of the row.
	/// The 'statusRow' is updated when the status of a recipient changes.
	///
	/// Note: Since we need 4 bits to store a status, one row of the bitmap can hold the status information of 256/4 recipients.
	///
	/// For example, if we have 5 recipients, the bitmap will look like this:
	/// | recipient1 | recipient2 | recipient3 | recipient4 | recipient5 | 'rowIndex'
	/// | 0000 | 0001 | 0010 | 0011 | 0100 | 'statusRow'
	/// | none | pending | accepted | rejected | appealed | converted status (0, 1, 2, 3, 4)
	///
	struct ApplicationStatus {
	uint256 index;
	uint256 statusRow;
	}

I added some on foundry test, but only recipient[0] got accepted. what's wrong?
others return 0, the same things happened on deployed strategy
event was emitted but status not changed.

    function __register_accept_recipient() internal returns (address recipientId) {
        recipientId = __register_recipient();
        address recipientId2 = __register_recipient2();
        address recipientId3 = makeAddr("recipientId3");
        uint256 refRecipientsCounter = strategy.recipientsCounter();

        address[] memory recipientIds = new address[](3);
        recipientIds[0] = recipientId;
        recipientIds[1] = recipientId2;
        recipientIds[2] = recipientId3;

        DonationVotingMerkleDistributionBaseStrategy.ApplicationStatus[] memory statuses =
            new DonationVotingMerkleDistributionBaseStrategy.ApplicationStatus[](3);
        statuses[0] = __buildStatusRow(0, uint8(IStrategy.Status.Accepted));
        statuses[1] = __buildStatusRow(1, uint8(IStrategy.Status.Accepted));
        statuses[2] = __buildStatusRow(2, uint8(IStrategy.Status.Accepted));

        vm.prank(pool_admin());
        strategy.reviewRecipients(statuses, refRecipientsCounter);
        strategy.getRecipientStatus(recipientId);
        strategy.getRecipientStatus(recipientId2);
        strategy.getRecipientStatus(recipientId3);
    }

[tnkshuuhei]

my questions are:

• what am I missing? (or wrong params)
• any good way to pass those params(ApplicationStatus[]) on frontend?

[codenamejason]

recipientId = __register_recipient();
address recipientId2 = __register_recipient2();
address recipientId3 = makeAddr("recipientId3"); // not registered

Recipient 1 & 2 should be accepted and 3 not. I can't see your __register_recipient2() function to verify 2 .

[tnkshuuhei]

__register_recipient2() is here, this is prepared function. I didn't modify anything.
as you said recipient2 should be accepted.

allo-v2/test/foundry/strategies/DonationVotingMerkleDistributionBase.t.sol

Lines 875 to 884 in 14ef520

	function __register_recipient2() internal returns (address recipientId) {
	vm.warp(registrationStartTime + 10);
	Metadata memory metadata = Metadata({protocol: 1, pointer: "metadata"});
	__isOwnerOrMemberOfProfileTrue();
	vm.prank(address(allo()));
	bytes memory data = abi.encode(profile2_anchor(), randomAddress(), metadata);
	recipientId = strategy.registerRecipient(data, profile2_member1());
	}

[0xKurt]

1 and 2 should be accepted
and 3 not

recipientId = __register_recipient();
address recipientId2 = __register_recipient2();
address recipientId3 = makeAddr("recipientId3"); // not registered

[tnkshuuhei]

I answered here.
#457 (reply in thread)

why this strategy is using bitmap instead of recipientid, status struct?
like this strategy is doing

allo-v2/contracts/strategies/_poc/sqf-superfluid/SQFSuperFluidStrategy.sol

Line 419 in 14ef520

function reviewRecipients(address[] calldata _recipientIds, Status[] calldata _recipientStatuses)

[0xKurt]

Tldr: using a bitmap makes the review of many recipients cheaper

[tnkshuuhei]

indeed, that makes sense.

@0xKurt @codenamejason
btw I modified them on my local env, and passed all test (hardcoded in hurry).
I think this is more intuitive and easier to use. we can compare GAS.
tnkshuuhei@8e42353

[tnkshuuhei]

one more question, how bitmap is gonna be if we have more than 64 recipient?