Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(DvA) Add DvA Transfer Manager #171

Merged
merged 18 commits into from
Nov 6, 2023
Merged

Conversation

aliarbak
Copy link
Contributor

@aliarbak aliarbak commented Oct 5, 2023

No description provided.


// solhint-disable-next-line code-complexity
function _approveTransfer(bytes32 transferID, Transfer storage transfer) internal returns (bool allApproved) {
bool approved = false;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I could implement this logic in a simpler way. I'm open to any suggestions 😅

@Nakasar
Copy link
Contributor

Nakasar commented Oct 11, 2023

We store the list of approvers in the _transfers mapping. This means if a user initiates a transfer, then the approval criteria are modified, then the transfer would still use the criteria at the date it was initiated and not the updated ones. Is this expected (I couldn't see any mention of this in the specs so maybe not)?

@aliarbak
Copy link
Contributor Author

We store the list of approvers in the _transfers mapping. This means if a user initiates a transfer, then the approval criteria are modified, then the transfer would still use the criteria at the date it was initiated and not the updated ones. Is this expected (I couldn't see any mention of this in the specs so maybe not)?

Not sure, I'll ask 👍

@aliarbak
Copy link
Contributor Author

aliarbak commented Oct 17, 2023

We store the list of approvers in the _transfers mapping. This means if a user initiates a transfer, then the approval criteria are modified, then the transfer would still use the criteria at the date it was initiated and not the updated ones. Is this expected (I couldn't see any mention of this in the specs so maybe not)?

Hey @Nakasar,
The final business decision here: If approval criteria change after a transfer is initiated, we need to reset the transfer's approval state (and invalidate all previous approvers).

And when an approver approves a transfer after the criteria change, it needs to reset the approval state and return. S/he needs to call the approve function one more time to be able to approve. This is the expected behavior.
(I updated the contract btw)

CHANGELOG.md Outdated
@@ -16,6 +16,7 @@ All notable changes to this project will be documented in this file.
constant variable to be declared.
- Add `function isPlugAndPlay() external pure returns (bool)` to `IModule`. Compliance modules now require this function to be declared. It indicates whether the compliance can be bound without any presetting.
- Add `function canComplianceBind(address _compliance) external view returns (bool)` to `IModule`. Compliance modules now require this function to be declared. If it returns false, it means some presets must be made before compliance can bind to the module.
- DVATransferManager contract
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be good to describe the contract a bit here

}

struct ApprovalCriteria {
address tokenAddress;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
address tokenAddress;

As the ApprovalCriteria is given by a mapping(address => ApprovalCriteria) with address being the token address, it feels redundant to have it in the struct

* DVATransferManager must be an agent of the given token
* emits an `ApprovalCriteriaModified` event
*/
function modifyApprovalCriteria(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure about the naming here. modify implies that the ApprovalCriteria already exists, while in fact this function is also used to set initial ApprovalCriteria
In this case i guess the terminology setApprovalCriteria would be more relevant

* @param includeAgentApprover determines whether the agent is included in the approver list
* @param sequentialApproval determines whether approvals must be sequential
* @param additionalApprovers are the addresses of additional approvers to be added to the approver list
* Only an agent of a token can call this function
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agents on T-REX are in charge of operational tasks such as minting, burning, freezing, recovering lost tokens, etc. Here i believe the task is more related to the general transfer rules management for the token, which is under the owner scope in T-REX, in the same way that it is the token owner that specifies the compliance rules, or the eligibility rules, i believe it should be the Token owner specifying the approval criterias in DvA

* @param amount is the transfer amount
* Approval criteria must be preset for the given token address
* Receiver must be verified for the given token address
* emits a `TransferInitiated` event
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could add that the sender should give allowance first to the DvA smart contract address on the token contract, and that this allowance needs to be at least amount


IToken token = IToken(tokenAddress);
if (!token.identityRegistry().isVerified(recipient)) {
revert RecipientIsNotVerified(tokenAddress, recipient);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe would make sense to also test canTransfer with address _from being the DvA address and _to the recipient for amount, to be sure that after approval, the transfer will be allowed to happen. Or maybe this is a bit overkill...

Copy link
Contributor Author

@aliarbak aliarbak Oct 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


bool transferSent = token.transferFrom(msg.sender, address(this), amount);
if (!transferSent) {
revert TokenTransferFailed(tokenAddress, msg.sender, address(this), amount);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this code is reachable. When transfer fails it reverts, therefore i don't see how we could get the case where transferFrom returns false and reach this code. I would therefore remove this part and the custom error that goes with it

function _transferTokensTo(Transfer memory transfer, address to) internal {
bool transferSent = IToken(transfer.tokenAddress).transfer(to, transfer.amount);
if (!transferSent) {
revert TokenTransferFailed(transfer.tokenAddress, address(this), transfer.sender, transfer.amount);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same remark as for transferFrom above, this code is not reachable, transfer either returns true or reverts. therefore it is not possible to get access to this case in which the transfer returns false and reach this custom error

@Joachim-Lebrun
Copy link
Collaborator

@aliarbak we should also have an implementation contract for DvA

@aliarbak
Copy link
Contributor Author

all done @Joachim-Lebrun

@Joachim-Lebrun Joachim-Lebrun merged commit 8e81b5e into develop Nov 6, 2023
3 checks passed
@Joachim-Lebrun Joachim-Lebrun deleted the dva-transfer-manager branch November 6, 2023 12:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants